Re: [TF-TD] Meeting minutes + TD Tutorial

> On 25 Aug 2015, at 16:36, Kaebisch, Sebastian <sebastian.kaebisch@siemens.com> wrote:
> 
> You are right, the “switching on” functionality may be also defined as a property. However, some people also see this as an action (I already had a long discussion about that ;-) ). I think, there will be always cases which both cases fits quite well, however, there will be also some more complex actions (e.g., dimming lights over time).

Indeed. Developers would have a choice in how they model things. We could provide some guidelines to help them with that task. Reading and assigning values for an object property is simpler to script than having to call methods and define call back handlers. The aim is to simplify the job of the IoT developer and not require them to deal with the transport layer concerns.
 
> [SK] I don’t understand the motivation of assuming that updates to properties are always automatically notified. Let me give you 4 examples, where this does not make sense: 
> 1) Let’s assume there is a battery powered client that only wants to request a temperature property of a remote Thing when the client is awake for few seconds before it go sleep for the next 10min. Why should the remote Thing always send a notification to a sleeping client if the temperature is updated? Apart from that we would waste network bandwidth and other resources.
> 2) Assume you have a property that serves complex data type including 20 data elements and a client is only interested in 1 or 2 data elements in there. If there always a high frequently change of the other 18 data elements then a notification will be always send without any valuable interest of the client.
> 3) Typically, there will be also some static properties (value is never changed) provided by a Thing, however, which may be not transparent to the clients. It would be wasteful if the clients should always set up an update handler for these kind of properties.
> 4) If you have a fan-out situation where one client accessing many Things or one Thing is accessed by many clients always transferring the complete status is very inefficient. 
>  
> So, I think the concrete application or scenario should decide if there is a interest of subscription of a property when there is an update. In addition, a Thing should also decide which kind of its properties should be observable or not (e.g., to avoid example 3).
>  
> What is missing now in the current model is a kind of an observable flag in the Property field. Another approach can be that the Event can be defined as a specialization of a Property. What do you prefer? 

I would characterise the problem differently.  

Sometimes, you want a thing to signal when a property has been applied to a device so that the user experience can indicate the lag between the user changing a setting, and it being applied. This is likely to be the base for a battery operated device that spends most of its time asleep, so that you need to wait for it to wake up before you can send it the update.

In other situations, this feedback is unimportant, and would be redundant.  This could be the case where a script is controlling things in the absence of a user, so the user experience is irrelevant. The need for a thing to notify its proxies when an update initiated by a proxy has been applied could be indicated by metadata for that property. My view would be that applications can set metadata in essentially the same way that they can set writeable properties.

There is a need to communications metadata, e.g. for batching of updates when timeliness is less of an issue , whether a notification is needed when a property update takes effect, whether timestamps are needed, sleep patterns for battery operated devices, and so forth. Metadata allows the transport layer to do a good job whilst keeping scripting at the application layer simple.

Going back to your example, the client spends most of its time asleep, waking up when a hardware interrupt occurs, or at a prescribed interval. The client needs the value of a property for a thing hosted on another device. If we assume that the other device is permanently on, then when the client wakes up, it could contact the other device for any pending messages. Alternatively the other device would know when the client is due to wake up and send the messages appropriately.  When both devices sleep as in a sensor network, life gets more complicated, but essentially, the devices need to agree on when they will be awake.

I believe it is important to maintain a clear distinction between the application and transport layers if we are to enable the web of things to work over different protocols and different communication contexts.  The application layer has properties. The transport layer deals with messages and notifications. The layers are coupled through the metadata that controls how the transport layer operates.

>  [SK] Yes, we should provide this kind of information and maybe additional metadata for protocols. I will update this in the tutorial. Just for my understanding: What is the use case of the prioritization?  

It covers the situation where a pair of servers have multiple protocols in common, and a server wants to indicate a preference to which protocol is to be used, perhaps for operational reasons.

Best regards,
—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>