On 05/17/2018 03:14 PM, Gregg Reynolds wrote: > On Thu, May 17, 2018, 8:23 AM Mats Wichmann <[email protected]> wrote: > >> On 05/17/2018 12:03 AM, Max wrote: >>> Hi, >>> >>> I wonder what should happen in the following scenario: >>> >>> >>> - A client registered an observer for a server resource. >>> - That server resource is gracefully terminated by the server, for >>> example using OcPlatform.unregisterResource() of Java API. >>> >>> Questions: >>> >>> - Does the spec require the server to notify the "observing" client? >> >> It's a little fuzzy, unfortunately. The OCF spec leaves the conditions >> that generate a notification entirely to the server, so a strict reading >> says it could choose not to bother in this case and it would still be >> correct operation. I'm not entirely happy about that (I worked a bit on >> this part of the spec, back in the day): Observe RFC, on which the OCF >> work is largely based, >> is not definitive that a notification must be sent - notice the word >> SHOULD: >> >> (RFC 7641, section 4.2): >> However, in the event that the state of a resource changes in >> a way that would cause a normal GET request at that time to return a >> non-2.xx response (for example, when the resource is deleted), the >> server SHOULD notify the client by sending a notification with an >> appropriate response code (such as 4.04 Not Found) and subsequently >> MUST remove the associated entry from the list of observers of the >> resource. >> > > Makes perfect sense to me. It's one thing to "observe" temperature; it's a > whole 'nother thing to observe the temperature instrument. > > If you observe the temperature, and the instrument goes down, you don't get > any more notifications. > > "...the underlying intent was that > each notification would be sent as if a resource retrieve had been sent > just that moment..." > > That does not make sense to me. You send a notification when resource state > changes. If the temp resource goes down, that is not a change of temp > state. So ".. as if.. " only makes sense when the resource is up.
well, we can swing back to that discussion of "what is a resource" - if it's conceptually fairly close to what you think about as Things in IoT, then create and delete resources aren't that obviously useful, but if they're more abstract, they could be. The C++ (and thus Java) APIs do let you do things in that area so we have to think about it. But putting that aside... all I was saying was, if you asked to GET on a resource that doesn't exist, then you'd expect to get back a "resource not found". so therefore *if* a server chooses to notify you that a resource went away, the way to do that in the observe scenario is send a message that says "not found" - just as if someone had just asked, rather than having asked seconds, minutes or hours ago to observe the resource, when it did exist. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9588): https://lists.iotivity.org/g/iotivity-dev/message/9588 View All Messages In Topic (5): https://lists.iotivity.org/g/iotivity-dev/topic/19267974 Mute This Topic: https://lists.iotivity.org/mt/19267974/21656 New Topic: https://lists.iotivity.org/g/iotivity-dev/post Change Your Subscription: https://lists.iotivity.org/g/iotivity-dev/editsub/21656 Group Home: https://lists.iotivity.org/g/iotivity-dev Contact Group Owner: [email protected] Terms of Service: https://lists.iotivity.org/static/tos Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub -=-=-=-=-=-=-=-=-=-=-=-
