Subject: [core] core-interfaces: rationale behind resource observation *attributes*

From: chrysn <[email-masked]>
Date: Tue, 23 Apr 2013 02:39:31 +0200

hello,

draft-shelby-core-interfaces-05 introduced a modification to the
observation parameters, where observations that would in -4 look like
this:

> Req: GET Observe /s/temp?pmin=10&pmax=60&st=1
> Res: 2.05 Content Observe:0 (text/plain)
> 23.2

would turn into this:

> Req PUT /s/temp?pmin=10&pmax=60&st=1
> Res: 2.04 Changed
> 
> Req: GET Observe /s/temp
> Res: 2.05 Content Observe:0 (text/plain)
> 23.2

this seems to be a modification for the worse, for it introduces a
global state on the server (which previously resided in the observe
subscription that is stateful by design). if two subscribers connect,
the second will overwrite the observation parameters the first
configured. if the intention is that the parameters that are configured
at connection time stay valid for the connection, that's still open for
race conditions.

what was wrong with the old solution, and why was the new one chosen to
supersede the old one?

best regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Zach Shelby <[email-masked]>
Date: Tue, 23 Apr 2013 10:40:38 +0300

Hi,

> what was wrong with the old solution, and why was the new one chosen to

Right, let me answer that first. The old model was not compatible with caching. In other words, /s/temp?pmin=10 and /s/temp?pmin=20 are completely different resources from the cache perspective, so in the old model an intermediate or client side cache would not be able to handle a simple request for /s/temp as it would have no cache entry. Observe is extremely useful for keeping a cache updated, thus we don't want to loose that.

For that reason, the parameters for Observation control are now treated as resources rather than query string parameters included with the Observe request. The endpoint still has a lot of flexibility in dealing with these parameters, they could be stored per client, thus giving you the same effect as in the original model but requiring more RAM, or they could be aggregated across all clients, saving RAM. 

That said, CoRE Interfaces is meant to give best practices on how to design resources for use with CoRE specifications. It doesn't mean this is the only way to design REST interfaces over CoAP, you could certainly use another paradigm if caching for example is not of importance. Although at the same time, using a common REST design has advantages too. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net