[ExposedThing] Not possible to handle event subscriptions in Scripting level

[egekorkan]

Coming from this issue in node-wot.

Use case: A reverse proxy implementation consumes a physical Thing in a local network and reexposes it as a new virtual ExposedThing to another network. A consumer of the virtual ExposedThing subscribes to an event. The issue is that there is no way to detect and handle a new subscription so that the proxy can subscribe to the event in the physical Thing. A non-optimal solution is to subscribe to the events of the physical Thing in the beginning (without any subscription) and reemit them when the events come to the proxy.

Proposal: Create two new methods in the ExposedThing interface, one to handle the subscription and one to handle unsubscription. These could be similar to setPropertyReadHandler. Example:

• setEventSubscribeHandler(eventName, ? subscriptionPayload, ? subscriptionCount): This could also solve the handling of subscription payloads. A subscription count would be interesting if the implementation wants to limit the number of subscriptions due to resource constraints.
• setEventUnsubscribeHandler(eventName, ? cancellationPayload, ? subscriptionCount): Similar to the above

[zolkis]

The API would be more like

partial interface ExposedThing {
    ExposedThing setEventSubscribeHandler(DOMString name, EventListenerHandler handler);
    ExposedThing setEventUnsubscribeHandler(DOMString name, EventListenerHandler handler);
};
callback EventListenerHandler = Promise<void> (optional any additionalData,
        optional InteractionOptions options = null);

There is the same signature for both subscribe and unsubscribe, the first gets the eventual subscriptionData, the latter the cancelationData. It makes sense to expose these on the server side.

[zolkis]

Actually, additionalData could be well added to InteractionOptions (a Scripting specific construct).

[zolkis]

I have made these changes, but have doubts about do we really need script defined handlers for subscriptions. When writing the algorithms, I realized that implementations can trivially do/generate the code for that, which is the reason these have not been included from the start.

So we need to check if we have the same understanding on how event subscription should be implemented and what is the value to open a hook for apps.

[egekorkan]

I would imagine a code snippet like the following for a proxy:

myProxy.setEventSubscribeHandler(buttonPress, {
  myRealThing.subscribe(buttonPress)
}

I don't think that this is so trivial when we don't have the Scripting API construct for it.

[zolkis]

On the Scripting call on 20. April 2020, we clarified that these handlers would not just extend default handling, but completely define it. That would cover the proxy case.