onObserve() cannot be used for both Property change notifications and Event notifications -- and should be removed alltogether

[mkovatsc]

Property change (or change-of-value/CoV) notifications are fundamentally different from Events that have an identity on their own (e.g., such Events must not be lost while CoV notifications can).

onObserve() should be fully ignored by scripts and completely handled by the WoT Runtime. A possible onNewObserver() shall be kept in implementtion space, i.e., outside standardization for now.

Similarly, there is no need to standardize an onSubscribe() because the user shall not be required to manage this; the WoT Runtime needs to. The user/script only emits Events.

[zolkis]

onObserve() is an application defined handler for observe requests, not to be confused with event handling. Please read the text.
Scripts do need to define a handler for requests in ExposedThing, including observe requests for everything that emits an event on the ConsumerThing counterpart:

• when a property value has changed
• when an action was invoked
• when a TD is changed.

Do you want to drop this feature?

[mkovatsc]

The text for onObserve() says

request.name defines the name of the Property or Action or event to be observed.

Overall, the issue already starts in ConsumedThing.observe() where it is used also for both, CoV and stand-alone Events -- not sure what observing an Action means. While we can use the concept of Observables for both, the theory behind observing CoV and subscribing to Events is different as indicated above.

I would like to focus first on what is fundamentally required for scripting WoT mashups (cf. PHP vs Jetty). Lets open a bucket for these "maybe nice to have calls" and remember them. Once we have a minimal viable Scripting API, we can still bloat it up.

[mkovatsc]

Digging in further shows that Events in the Scripting API are not aligned with Events in the TD model.

As of now, the TD Interaction Model foresees

• Observable Properties, which can push change-of-value notifications (which only need eventual consistency, so intermediate notifications may be lost or even filtered to reduce the load)
• Events, which define sources of individual event instances. Clients can subscribe to sources and each event instance must be transferred from the source to the client.

This difference should also be reflected in the Scripting API with different calls. Both may make use of the Observer programming pattern.

[zolkis]

That is right, this is work to be done. We track that in issue #68.

[zolkis]

Addressed by #86.