AW: [GitHub] Organizing the repository

Hey Michael,

I’ve been thinking exactly about the same topic - the conclusion was a bit different for me:
I agree that on a protocol level (i.e. for mapping) it makes sense to differentiate if the receiver of notfications keeps an open channel (case 1) or just registers und unregisters a callback (case 2).

For an application however, the difference is very subtle – there is something where it needs to get updated about and it gets updates.

Regarding the WoT architecture, this difference could show up on the resource layer, where it is natural to have a receiving resource for “case 2”, but might feel artificial to create resources for “case 1” – I still would recommend doing so, and here is why: with Observe, EventSource, GET-Upgrade, MQTT sub etc.  you have some hidden state e.g. how many subscriptions are already there.
This is in any practical setup little issue in desktop and cloud environments (except for extreme fan-outs), but can have important impact on constrained devices.
Using something like subscription resources also for this case can make that visible/debuggable/manageable, plus some nice features like e.g. most protocols tie that state to the connection, enabling a one-stop view of connected subscribers etc.

Best regards,
Johannes

Von: Michael Koster [mailto:michael.koster@smartthings.com]
Gesendet: Montag, 2. Mai 2016 15:31
An: Hund, Johannes (CT RDA NEC EMB-DE)
Cc: Kovatsch, Matthias (CT RDA NEC EMB-DE); Charpenay, Victor (CT RDA NEC WOS-DE); Public Web of Things IG; Soumya Kanti Datta; louay.bassbouss@fokus.fraunhofer.de; tkamiya@us.fujitsu.com
Betreff: Re: [GitHub] Organizing the repository

Great, here is some more discussion.

I agree that events are different from state changes of properties, and I think they can use some common system design patterns. and have. Subscription is a useful term for the process of registering intent to recieve notifications, but may be overloaded already. We also use publish/subscribe interfaces like MQTT which also have subscription methods.

We could define "Subscription" in a consistent way for both Events and Properties as the process of registering for notifications, and use the asynchronous communication pattern of "Notification" for both events and property state change propagation.

But there are 2 kinds of subscription; one is like CoAP Observe, HTTP EventSource or MQTT subscribe, where a program makes a request and provides a handle for asynchronous callbacks. The second kind where the state of a resource is observed by a monitor and pushed to another resource (URI). This can modify another resource state but is more difficult to connect to a callback handler. The pushed-to resource then needs to be observed in order to generate program callbacks.

Both events and state changes generate notifications and can be subscribed to, but the behavior has some subtle differences:

Case 1:  Software application does an extended read operation and receives notifications (CoAP Observe, HTTP SSE, MQTT Subscribe operation)
Case 2: A control is created to monitor a specific resource and send state updates to another resource (CoRE Interfaces Link Binding, WoT Subscription resource)

I think we need two different terms for these, and I have been using "Observe operation" for the first case and "Binding" for the second case. I leave "subscription" to describe the pub/sub case only, even though it is similar to Observe.

Likewise a state update in Case 1 is a response to a particular operation on the resource. A state update in Case 2 is an unsolicited transaction. I have been calling Case 1 "Notification and Case 2 "Publishing"

Also, when we invoke an action, there is an observe/notify relationship with the new actuation resource which can reuse either of these patterns, but most likely to use Case 1.

In the implementation, it has been useful to make one method for registering with a resource that is used by both program observation and bindings.

I am preparing a contribution as a follow on to my earier article to propopse a consistent protocol for these operations, and the most difficult part seems to be the nomenclature.

Best regards,

MIchael


On May 2, 2016, at 5:46 AM, Hund, Johannes <johannes.hund@siemens.com<mailto:johannes.hund@siemens.com>> wrote:

Yes, we could do that.

That write-down was born out of the need to have something on resource-layer to enable protocol-agnostic subscriptions for events and/or bindings or however we might call those two types, so it might be good to have the neutral term.

BR

Von: Kovatsch, Matthias (CT RDA NEC EMB-DE)
Gesendet: Montag, 2. Mai 2016 13:55
An: Charpenay, Victor (CT RDA NEC WOS-DE); public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>; michael.koster@smartthings.com<mailto:michael.koster@smartthings.com>; Hund, Johannes (CT RDA NEC EMB-DE)
Cc: Soumya-Kanti.Datta@eurecom.fr<mailto:Soumya-Kanti.Datta@eurecom.fr>; louay.bassbouss@fokus.fraunhofer.de<mailto:louay.bassbouss@fokus.fraunhofer.de>; tkamiya@us.fujitsu.com<mailto:tkamiya@us.fujitsu.com>
Betreff: RE: AW: [GitHub] Organizing the repository

Indeed we need to clarify the topic "events". Carsten Bormann had a nice writeup of the two distinct flavors.

Should we collect the discussion/survey/conclusion in your spin-off activity? Then I would leave the more neutral term "subscriptions" for now.

Ciao
Matthias


Sent from my Android phone using Symantec TouchDown (www.symantec.com<http://www.symantec.com/>)

-----Original Message-----
From: Hund, Johannes (CT RDA NEC EMB-DE) [johannes.hund@siemens.com<mailto:johannes.hund@siemens.com>]
Received: Monday, 02 May 2016, 12:30
To: Kovatsch, Matthias (CT RDA NEC EMB-DE) [matthias.kovatsch@siemens.com<mailto:matthias.kovatsch@siemens.com>]; Charpenay, Victor (CT RDA NEC WOS-DE) [victor.charpenay@siemens.com<mailto:victor.charpenay@siemens.com>]; michael.koster@smartthings.com<mailto:michael.koster@smartthings.com> [michael.koster@smartthings.com<mailto:michael.koster@smartthings.com>]; public-wot-ig@w3.org<mailto:public-wot-ig@w3.org> [public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>]
CC: Soumya Kanti Datta [Soumya-Kanti.Datta@eurecom.fr<mailto:Soumya-Kanti.Datta@eurecom.fr>]; Bassbouss, Louay [louay.bassbouss@fokus.fraunhofer.de<mailto:louay.bassbouss@fokus.fraunhofer.de>]; Takuki Kamiya [tkamiya@us.fujitsu.com<mailto:tkamiya@us.fujitsu.com>]
Subject: AW: [GitHub] Organizing the repository
> @Johannes: I will move your temporary item to https://github.com/w3c/wot/tree/master/proposals/subscriptions -- unless this is the basis for our events design pattern, in which case I would call it https://github.com/w3c/wot/tree/master/proposals/events :)

Perfect thanks.
Regarding the name:
Names are "seach-replace", but I think we should pick up this discussion and have two distinct concepts and glossary terms for "state changes as updates to sync resources" and "distinct events", whatever the names are then.

BR Johannes