Do we need an EventHandler?

[relu91]

In the Handling Events flow, we are stating that if data is null or undefined the runtime should ask the internal slot eventHandler to return something for sending it to the network.

However, I don't think we have such a use case: a caller does not know what to send for a particular event and defers the decision to the backend logic of an ExposedThing.

This choice makes also it quite inconvenient to cover the use case described in #402. In other words, if an event has not data here's the code needed to implement it:

var produced; // Produced Thing
produced.setEventHandler("noDataEvent", () => undefined);
// exposing
await produced.expose();
produced.emitEvent("noDataEvent");

Whereas if we just rely on the data passed on the emitEvent method we could simply:

var exposed;
exposed.emitEvent("noDataEvent");

[danielpeintner]

Call 2022-07-04

• recall use-case from TUM having this handler, @danielpeintner will look it up

[egekorkan]

I am not 100% sure but this was about implementing a shadow thing or a proxy. I am proxying a local thing to the public network and before having this event handler, the proxy would subscribe to all events even if there is no consumer of the proxy interested in some of the events. With the event handler, when a subscription request comes to the proxy, it will subscribe in the event handler.

However, I think I am not seeing something since in my point of view, there is no difference in an event having data or not.

[danielpeintner]

The issue @egekorkan is mentioning is #211.

I "think" the issue is the same for events and observing property changes...

[danielpeintner]

Call 2022-07-11
Maybe @egekorkan has a "picture/diagram" to show the problem... network configuration/setup. We were not 100% sure.
@egekorkan would you have time to join a call once?

[egekorkan]

I can join next week. I think that I have confused it with eventsubscription handler

[danielpeintner]

Call 2022-07-18

• agreed that there is no need for EventHandler
• check whether we can merge Section 9.28 and 9.29
• @relu91 will work on PR

[zolkis]

agreed that there is no need for EventHandler

Let's record the justification in more detail, please. I wonder if we all mean the same things and use cases about this EventHandler.

• The context is ExposedThing, but specifying a customized (hooked) ConsumedThing side (how to handle events, for instance in case of Thing proxy implementations)
• In contrast, emitEvent() is the ExposedThing side
• Constructing an ExposedThing starts with a TD that defines event names
• The code for ExposedThing defines the behavior by adding functions that interact with the underlying platform and implement the interfaces of event handling,
• then register them as handlers for various interactions

So far the handler for handling events in ExposedThing has been defined by a user-defined function.

So are we now saying that:

• there is no need for user-defined event handler functions in ExposedThing, i.e. no hooks are possible and the WoT Scripting API implementations must implement and use a default event handling?
• if so, what is the algorithm for event handling, is it standardized, or is it left to the implementations?

I'd say if there are no strong use cases for the EventHandler hook on ExposedThing, we should indeed remove it, to simplify the spec.

[danielpeintner]

Call 2022-08-08

• at the moment there is no strong use-case for keeping the EventHandler, see Do we need an EventHandler?  #408 (comment)