Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: use TD default values #537

Open
derwehr opened this issue Jan 25, 2024 · 4 comments
Open

Proposal: use TD default values #537

derwehr opened this issue Jan 25, 2024 · 4 comments
Labels
use case Describes a scenario that may be useful for technical decisions

Comments

@derwehr
Copy link

derwehr commented Jan 25, 2024

hello,
I'd like to propose the scripting API to define variables the consumer leaves undefined with the default values from the TD (or const values?).

A simple use-case would be a Thing, expecting a fixed payload parameter based on the Interaction Affordance, like in the TD below.

Now with the scripting API using the default values a user won't have to worry about knowing the correct commandId.

{
  "actions": {
    "move": {
      "type": "object",
      "properties": {
        "commandId": {
          "type": "integer",
          "default": 5
        },
        // other dynamic properties like coordinates
      }
    },
    "dimLight": {
      "type": "object",
      "properties": {
        "commandId": {
          "type": "integer",
          "default": 6
        }
        // other dynamic properties like time span
      }
    }
  }
}
@danielpeintner
Copy link
Contributor

Are you referring to the Consumed or Exposed side?

e.g., on ExposedThing side
Do you mean that a Scripting API implementation needs to look into the DataSchema and detect whether it has default or const and report it accordingly without adding a handler?

@derwehr
Copy link
Author

derwehr commented Jan 29, 2024

On the ExposedThing side.
If I understand it correctly, then a TD already describes this case perfectly and there should not be a need for adding handlers.

@relu91 relu91 added the use case Describes a scenario that may be useful for technical decisions label Jan 29, 2024
@relu91
Copy link
Member

relu91 commented Jan 29, 2024

Call 29/01:

  • @zolkis from the ExposeThing side is saving 1 line of JS, but there might be even more use case for different automation needs. Is it really worth it?
  • @danielpeintner agrees, I see the use case but it is not that much work. Plus it adds complexity to the implementation (you need a full jsonschema parser)
  • @relu91 even from the Consumer side could be added but it is still not that much different.

@derwehr
Copy link
Author

derwehr commented Jan 29, 2024

Thank you for discussing my proposal :)
My understanding of the WoT is that when adding new devices to a WoT application or exchanging existing ones, ideally, you'd only need to consume a TD and should not need to modify any code. Therefore, I'm trying to describe everything in the TD and to avoid adding handlers.
Would my proposal to improve this 'out of the box TD compatibility' be a better fit for other WoT specifications like the protocol bindings, or is this something every developer would decide upon independently?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
use case Describes a scenario that may be useful for technical decisions
Projects
None yet
Development

No branches or pull requests

3 participants