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. I'm not saying this is good, just that it is not ambiguous. > > - From IoTivity API perspective, assuming both client and server use > > IoTivity - should the client code get an error? > > > >>From my experience with a client using Java API, in some cases the error > > callback provided when calling the observe() method of OcResource is > > called, but in other cases there is no notification or callback. > > Sounds like the code is as fuzzy as the spec :( > > I bet we could use some documentation on this - the observe doc doesn't > say anything about the future, and the callback type doesn't say > anything at all (OCApi.h). > > > >
