W3C home > Mailing lists > Public > public-wot-ig@w3.org > May 2016

Re: [GitHub] Organizing the repository

From: Michael Koster <michael.koster@smartthings.com>
Date: Mon, 2 May 2016 06:30:50 -0700
Cc: "Kovatsch, Matthias" <matthias.kovatsch@siemens.com>, "Charpenay, Victor" <victor.charpenay@siemens.com>, Public Web of Things IG <public-wot-ig@w3.org>, Soumya Kanti Datta <Soumya-Kanti.Datta@eurecom.fr>, "louay.bassbouss@fokus.fraunhofer.de" <louay.bassbouss@fokus.fraunhofer.de>, "tkamiya@us.fujitsu.com" <tkamiya@us.fujitsu.com>
Message-Id: <FBD6DDA7-701D-40F9-8052-1DD57068F2C1@smartthings.com>
To: "Hund, Johannes" <johannes.hund@siemens.com>
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,


> On May 2, 2016, at 5:46 AM, Hund, Johannes <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; michael.koster@smartthings.com; Hund, Johannes (CT RDA NEC EMB-DE)
> Cc: Soumya-Kanti.Datta@eurecom.fr; louay.bassbouss@fokus.fraunhofer.de; 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]
> Received: Monday, 02 May 2016, 12:30
> To: Kovatsch, Matthias (CT RDA NEC EMB-DE) [matthias.kovatsch@siemens.com]; Charpenay, Victor (CT RDA NEC WOS-DE) [victor.charpenay@siemens.com]; michael.koster@smartthings.com <mailto:michael.koster@smartthings.com> [michael.koster@smartthings.com]; public-wot-ig@w3.org <mailto:public-wot-ig@w3.org> [public-wot-ig@w3.org]
> CC: Soumya Kanti Datta [Soumya-Kanti.Datta@eurecom.fr]; Bassbouss, Louay [louay.bassbouss@fokus.fraunhofer.de]; Takuki Kamiya [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 <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 <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

Received on Monday, 2 May 2016 13:31:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:03 UTC