-
Notifications
You must be signed in to change notification settings - Fork 25
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
Observable Properties #10
Comments
During the Burlingame 2017 PlugFest the notion of using the "link": [
{
"href": "coaps://mytemp.example.com/temp",
"mediaType": "application/json",
"rel": "read",
"http:methodName": "get"
},
{
"href": "coaps://mytemp.example.com/temp",
"mediaType": "application/json",
"rel": "observe",
"http:methodName": "get",
"http:messageHeader": [
{
"http:fieldName": 6, // Observe option
"http:fieldValue": 1
},
}
] |
Here is an example including the proposed "form" tag and a more realistic CoAP vocabulary, following the style of http in RDF. Also adding some OCF protocol binding settings. The methodName and fieldName items are just for human readability; the codes are used to fill in the CoAP message.
|
See unified example in #13 . Closing. |
The concept of Observable Properties is already in the TD Editor's Draft and might end up in the Scripting API Editor's Draft soon. However, it is still completely open, how this should work on the protocol level.
For CoAP and some HTTP extensions, a single entry could work in the protocol binding:
or
"observe": "http:longpoll"
.If reading the Property works through HTTP, but observing through WebSockets, we have a problem. Question is, if this case should even be in scope. A Thing providing this has to implement two different kind of interaction mechanisms anyway, so it could also simply model this as two Interactions: one normal Property and one Event.
Thoughts?
The text was updated successfully, but these errors were encountered: