-
Notifications
You must be signed in to change notification settings - Fork 63
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
Describing common event subscription pattern such as subscriptionId #887
Comments
Just for clarification on inputs and outputs for subscription and cancellation, the example from @sebastiankb uses the |
Mhh, maybe I wasn't super clear. |
Extract from the above example shows this: "subscription" : {
"type" : "object",
"properties" : {
"targetURL" : {
"type" : "string",
"format": "uri",
"writeOnly": true,
"description": "Requester provides the target URL to which Thing the event should be provided"
},
"subscriptionID" : {
"type": "integer",
"readOnly": true,
"description": "Responses an unique subscription ID."
}
}
}, So the I do agree that it is not how we are used to seeing things. If we think like this, everything in an action's input is |
Or they could be default+unmutable values (documented in the TD spec). |
To summarize discussion in March 27 TD call (minutes here):
Oracle implementation is in GitHub. (see here) . It was not clear whether this is a proprietary mechanism or it is based on some existing practices/standards. Any comments, @mlagally ? |
@takuki Thanks for the reminder. At this point it is a proprietary mechanism based on Webhooks. |
@mlagally do you have a date of presentation? then I can check the minutes. |
maybe we should also collect all (common) used event mechanism on the market such as
|
In WebSub, unsubscribe request results in the hub contact you for verification. See Section 5.3 Hub Verifies Intent of the Subscriber of WebSub specification. |
The issue comes from the Scripting API were we try to keep complexity minimal to do event subscription (or any other interaction).
Having said that, we think the TD is underspecified when it comes to eventing.
Let's assume a rather common use-case for subscribing to events (see lifecycle below)
The TD EventAffordance has 3 terms
subscription
with one DataSchema (most likely describing the input? But how to properly describe output such the subscriptionId)data
with DataSchema describing the event content (seems fine)cancellation
with one DataSchema describing input such like subscriptionId (Question, do we need output here also?)In general, we wonder whether it makes sense to collect some common use-cases (or eventing patterns) and try to experiment how these use-cases can be represented with the 3 aforementioned terms.
Issue relates to #817 and #812
The text was updated successfully, but these errors were encountered: