Event consumer: Alternative 2 - event consumer affordance

[mlagally]

Event consumer affordance to enable describing a servient with an event listener notification interface in a TD.

---

Preview | Diff

[egekorkan]

My review for both proposals: postpone to TD2.0 and avoid any kind of discussion that would imply more discussion time hence less time for making sure that the current specification is well specified.

Opinion in general:
Even though this is adding simply another affordance, the mechanism and the behavior behind is not well explained nor the use case is specified beforehand nor anything was tried out (I do not mean tested/validated, simply just tried out) in a plugfest. Even if this is possible and implementable, we did not consider any other approaches and we should simply not approach a standardization activity like TD this way which tries to make sure that we can describe Thing interfaces in a generic way and not specify the first way that comes to mind.

[relu91]

I'm afraid that I agree with @egekorkan. Although the proposal seems interesting is something completely brand new. As far as I remember we did even properly discuss which are the modalities on how we can extend the current interaction model. For example, we had a hard time figuring out how to introduce new operation types for async actions (a new affordance type might help to settle a long-standing discussion also there - JobAffordance).

if this proposal is about to push notifications (? I think we need a use case description), I would say is a paradigm shift... the affordance that we defined so far describes what a producer can do and not what it expects that a consumer would do. I'm confident that we can work on it but it requires time...

[mlagally]

As a fundamental WoT concept a Thing can be anything, event consumer, event producer, server, client, servient.
A TD should be able to describe these different kind of things, and I think the current interaction model already almost contains all what is needed.

I think the alternative 1 is more straight forward and pretty easy to implement, because it only requires to add another operation (notify) to define an event consumer.

[sebastiankb]

I'm agree with @egekorkan and @relu91. This proposal is more related for a potential TD 2.0 discussion. As I already mentioned we have currently the fundamental WoT paradigm “property, action and event”. This PR would cause a new affordance with “property, action, event, and eventConsumer” that would not only impact the TD spec, but also the conceptional description in Architecture as well as the Discovery, Binding Documents, Security and Profile docs.

[mlagally]

@sebastiankb Thanks very much for your comments.
I have provided an alternative proposal in #1329 which does not require a new affordance, but just adds a new operation. This will not have significant impact on the other normative documents, except for profile, where we need it for push events.
I have provided a sequence diagram and more explanations in issue #1323 and suggest to continue the discussion there, to avoid fragmented conversations in several places.

[sebastiankb]

@mlagally thanks for your response. Then I would suggest that we focus on proposal #1329 in this charter period.

[egekorkan]

TD Call 13.12:

• The issue Missing event/notification affordance or operation #1323 is already tracking this discussion.
• Changing the index.html alone would not suffice anyways so the PR is not mergeable as is.
• A discussion should happen first before agreeing on one of the PRs (i.e. Event consumer: Alternative 2 - event consumer affordance  #1330)
• The same will be commented at the other alternative
• Closing