-
Notifications
You must be signed in to change notification settings - Fork 28
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
Event Affordance subscription and cancellation payloads are not usable by scripting #208
Comments
The question is, from where the subscription and cancellation options (data) come from: application or implementation/bindings? If they come from the app, then:
If these come from the protocol bindings, then they need not be exposed to the app. What should be the behaviour if the app defines these, should the implementation try to use them (how) and signal error or ignore them? |
That's a very good question. Here are some TDs that define
In the case that this needs to be figured out by the implementation:
By the way, the one from Oracle has wrong description of uriVariables:
|
In the first case (Oracle) it seems that the subsciption/cancellation information exposes the full protocol details of the underlying implementation piggybacked via this optional data field. We don't have any benefit of using WoT here, since the app needs to know all the details anyway. This would be one reason why to not allow these options to interactions but keep them on bindings level because that would force a better design on the service. It is OK to include key management stuff, but that should be a WoT mechanism, not and Oracle mechanism disguised as subscription data. In the Siemens case, yes, that id could be managed by the underlying implementation. |
I am not sure where to go with this one. Apart from that, InteractionOptions should be supported by |
I think that it is due to the fact that we didn't experiment much with subscription and cancellation payloads by looking at what is the common practice. |
We might reconsider this. Please comment on the following use case that I described in w3c/wot-thing-description#1053:
|
That sounds like actions would be more fitting interaction types for this use case. They could accept parameters as context for special subscription + action for special canceling. |
Could you go more in-depth here? How would you model a push notification system based on a parameterized query with actions within the WoT interaction model? |
Maybe I can auto-answer 🤣 did you think about an action that returns a TD handle where you have the added and removed events parameterized by your in input in the action? Much like the discussed approach about long-running actions that never landed in something concrete sadly. |
It seems that the linked TD issue is w3c/wot-thing-description#1053. |
In the TD spec, the Event affordance has the
subscription
andcancellation
keys. With these keys, one can describe a payload that needs to be passed along for subscribing or unsubscribing from an event.In the Scripting API, this behavior is not specified explicitly for the subscribeevent method and is not specified at all for the unsubscribeevent method. For
subscribeevent
, it is said that one can useInteractionOptions
vocabulary which however says that currently they are used only for URI variables. Forunsubscribeevent
,InteractionOptions
do not seem to be even allowed.A further discussion would be whether these are actually interaction options or
params
like theinvokeAction()
method.The text was updated successfully, but these errors were encountered: