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

Observable Properties #10

Closed
mkovatsc opened this issue Oct 27, 2017 · 3 comments
Closed

Observable Properties #10

mkovatsc opened this issue Oct 27, 2017 · 3 comments

Comments

@mkovatsc
Copy link
Contributor

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:

"link": {
    "href": "coaps://mytemp.example.com/temp",
    "mediaType": "application/json",
    "http:methodName": "get",
    "observe": "coap:observe"
}

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?

@mkovatsc
Copy link
Contributor Author

mkovatsc commented Nov 7, 2017

During the Burlingame 2017 PlugFest the notion of using the rel attribute came up and it would look like this:

"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
      },
  }
]

@mjkoster
Copy link
Contributor

mjkoster commented Dec 5, 2017

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.

"form": [
  {
    "href": "coaps://mytemp.example.com/temp",
    "mediaType": "application/ocf+cbor",
    "rel": "observe",
    "coap:methodName": "GET",
    "coap:methodCode": "0.01",
    "coap:MessagelHeader": [
      {
        "coap:fieldName": "Accept",
        "coap:fieldCodeNumber": 17,
        "coap:fieldValue": 10000
      },
      {
        "coap:fieldName": "OCF-Accept-Content-Format-Version",
        "coap:fieldCodeNumber": 2049,
        "coap:fieldValue": "1.1.0"
      },
      {
        "coap:fieldName": "Observe",
        "coap:fieldCodeNumber": 6,
        "coap:fieldValue": 0
      }
    ]
  }
]

@mkovatsc
Copy link
Contributor Author

See unified example in #13 . Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants