On 05/17/2018 03:14 PM, Gregg Reynolds wrote:
> On Thu, May 17, 2018, 8:23 AM Mats Wichmann <m...@wichmann.us> 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: iotivity-dev+ow...@lists.iotivity.org
Terms of Service: https://lists.iotivity.org/static/tos
Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to