Subject: Re: [core] Proposal for a new subscription mechanism in CoAP

From: Vipul Gupta <[email-masked]>
Date: Tue, 22 Jun 2010 11:18:15 -0700

On Jun 20, 2010, at 8:51 AM, [email-masked] wrote:

> Date: Sun, 20 Jun 2010 11:16:43 -0400
> From: Paul Duffy <[email-masked]>
> Subject: Re: [core] Proposal for a new subscription mechanism in CoAP
> 
> On 6/20/2010 10:15 AM, Carsten Bormann wrote:
>> On Jun 20, 2010, at 15:49, Paul Duffy wrote:
>> 
>> 
>>> Subscriptions are resources. they are created, have a lifetime, are deleted, can be modified, can be enumerated.
>>> 
>> Why do you think that is the right design?
>> 
> 
> Two choices...
> 
> - a subscription URI as child to the subscribed parent URI.   
> protocol://{address}/somepath/subscription.  You subscribe directly to 
> the resource.  Very OO

This choice is also a great fit for situations where the implementation
of the subscription/notification mechanism is resource-specific.
In our experience with a REST-based service for collecting/analyzing/
subscribing to sensor data (http://sensor.network.com/), this is frequently
the case (illustrative example below).

If one thinks of resources on a device implemented as tiny applications
hosted inside a "nano" appserver (and this is actually how we are 
implementing things for Sun SPOTs, http://www.sunspotworld.com/) then 
each application gets to manage a part of the URI space including both
the resource and its subscriptions.

protocol://{address}/path_to_resource   (for resource)
protocol://{address}/path_to_resource/subscriptions (for resource subscriptions)
protocol://{address}/path_to_resource/subscriptions/id (specific subscription)

Note that the subscriptions subspace need not be labelled "subscriptions" because
it can be discovered using the mechanism described at 
http://webhooks.pbworks.com/RESTful-WebHooks under Discovery (based on "Web Linking"
http://tools.ietf.org/html/draft-nottingham-http-link-header-10).

Example: consider a tri-color LED and a light sensor both modeled as
resources (e.g. http://..../led4 and http://..../sensor1/light). An 
application might want to be notified when led4's color setting is
changed or when the light level falls below a certain threshold. In the case of
the LED, all state changes occur by explicit PUTs to the resource URI.
In the case of the light sensor, however, changes in the light readings occur
independent of any interaction with the resource URI. Hence the
mechanism for implementing notifications are resource specific -- the
former only requires monitoring of PUTs but the latter requires periodic 
sampling.

vipul
---
http://labs.oracle.com/people/mybio.php?c=509

> - a single subscription URI for the endpoint  
> protocol:.//{address}/subscription.  All subscriptions managed @ a 
> single URI.
> 
> Payloads defined appropriately
> 
>> The main job of what you are calling a subscription is to manage conversation state, things like transport addresses, as opposed to application state.
>> 
> 
> Disagree.  The main job of a subscription is to monitor changes to 
> application state, and alert interested parties to those changes in 
> application state.
> 
>> Why is the resource level the right way to manage that state?
>> 
>> I'm sure that this design can be made to work; I'm just wondering what its advantages and disadvantages are.
>> 
>> Let me illustrate this point with a couple of slight modifications of your statement:
>> 
>> 
>>> Connections are resources. they are created, have a lifetime, are deleted, can be modified, can be enumerated.
>>> Cached representations are resources. they are created, have a lifetime, are deleted, can be modified, can be enumerated.
>>> 
>> I'm pretty sure that in both cases this approach would lead to a contorted design; there is a reason why this state stays below the level of resources and their representation.
>> 
>> So what is it that makes the desire of one connector to remain informed about a resource, itself a resource?
>> (I'm not saying it is not, I just want to hear good arguments why that makes sense.  Or why it does not make sense.)
>> 
>> Gruesse, Carsten
>> 
>