AW: [TF-TD] Meeting minutes + Update TD Tutorial

> > Takuki Kamiya wrote:
> > How does “stability” helps other than the case of the value 0?
> >
> > For example, if the value is 10 seconds, clients know the value
> > is obsolete after 10 seconds passed. However, it is also likely that
> > the value has already changed after 8 seconds passed, for instance.
> > Then the client may want to check the property value even before
> > 10 seconds passed.

The initial discussion was if we need some indication if you can subscribe or observe a value (as in true/false).
The train of thought was to go beyond that and provide more information.

> Carsten:
> The idea that came up in the call was to have something in a Thing Description
> that might indicate the volatility of the resource state.
> (Expressing this in the inverse, as stability, has the advantage that we can
> use more handy periods in seconds.)

As Carsten points out, the idea of "stability" was to give a developer/user a hint how often he  should expect the value to change (we need a special value for "never" though).
If you can observe or subscribe, you would still get the value in 8 seconds, and you can plan in your application that you probably will not get 10 values per second or only once a day.
But if you can only poll, you would do it in roughly 10 seconds.

> Note that in all cases we still have MaxAge (in CoAP, or one of several
> equivalents in HTTP) for an actual current value with each GET; the Thing
> Description would only provide an expected value.

The max-age is used for cache-management of HTTP (and CoAP), our idea was to have roughly similar semantic which inversively can give a hint how volatile the value is.

What do you think?

Best regards,
Johannes

Received on Wednesday, 9 September 2015 09:37:46 UTC