Missing `EventSubscribeHandler` and `EventUnsubscribeHandler` implementation

[erkann-sen]

I have needed to make an action when an event in exposed thing is subscribed. But normal api only allows me to subscribe to an event unsubscribe or emit an event. To make it happen I dive deep in exposed_thing.js and it triggers an action when somebody is subscribed an event.

So my proposal is to have a callback for any developer to have knowledge if somebody subscribed to event. Something like thing.on_subscribed_to_event(eventName, subscribedCount)

I made this functionality by overriding push function of thing.events[eventName].getState().subject.observers array as a hacky way (code below).

But it also showed me another problem unsubscription does not make any change in subjects observers it does not remove the observers, they stay forever in this array so overriding pop function or relying on sub.observers.length
let sub = this.thing.events[eventName].getState().subject; sub.observers.push = function () { Array.prototype.push.apply(this, arguments); if (sub.observers.length == 1) { /*sth subscribed for the first time*/ this.handleFirstTimeSubscriptionForEvent(eventName); } };

[egekorkan]

Copied over to the Scripting API: w3c/wot-scripting-api#210

[egekorkan]

Note: This is also valid for observable properties

[zolkis]

Just for clarification, I am raising a question here at the source :).
I see 2 variants / use cases of the above:

1. modify behavior of remote Things (client API)
2. modify behavior of local exposed Thing (server API).

The first use case is usually not handled by generic mechanisms on client side.
IMHO we should not provide a client side hook in Scripting that would modify how events are dispatched in remote Things. That generic mechanism would be an open security breach.
The Thing where this behavior is desired should expose an explicit event when a subscription is made to another event, i.e. this should be included in the data model, not the generic Scripting mechanisms.

In turn, on the ExposedThing side it makes sense to provide a hook to scripts in order to override event signaling behavior. But that is a local effect on a service exposed by the script, not a modification of behaviour on a remote Thing. This one we can implement in Scripting.

Do we agree on this?

[erkann-sen]

Yes we agree, I guess I was not clear enough in the original issue.
I propose a function which is triggered in the local exposed thing like thing.on_subscribed_to_event(eventName, subscribedCount) which can be useful for a developer to see the subscriber count or if any subscription to any event occurred. Or any logic can be built upon this information like ifttt (if someone subscribed to this event, then activate an action)

[relu91]

Is this still relevant? did we add handlers for these events right?

[danielpeintner]

Note: The handlers are there but they miss implementation

see for example
https://github.com/eclipse/thingweb.node-wot/blob/eb1c4a2187bedcb457e13248873de85b39efa341/packages/core/src/exposed-thing.ts#L267-L274

[relu91]

I changed the title just to easily understand the real issue here.

[danielpeintner]

The handlers are in place now

https://github.com/eclipse/thingweb.node-wot/blob/b25b54cff2a9c3238400cef852c9cf757980e6e8/packages/core/src/exposed-thing.ts#L374

https://github.com/eclipse/thingweb.node-wot/blob/b25b54cff2a9c3238400cef852c9cf757980e6e8/packages/core/src/exposed-thing.ts#L397