Add 'once' to subscription options

[zolkis]

No description provided.

[relu91]

Seems ok!
Just one question:

If |options|' |once| is true, invoke |subscription|'s
stop() method with |options|

This means that I can't use a different set of options for unsubscribing when using once parameter. Correct?

[zolkis]

This means that I can't use a different set of options for unsubscribing when using once parameter. Correct?

The use case with once is that unsubscribe() is not called, therefore its |options| cannot be not specified. I think it is implementation specific how exactly stop() will use |options|. For use cases when unsubscribe options are needed, one could not use once, but implement it "manually" in the app. Actually this can be quite latent, which questions the actual utility of once.

[danielpeintner]

I am not totally opposed to this extension but

• it pushes complexity to the runtime (and if we open this door more is going to come)
• it is a half-baked solution given that "what if I want to subscribe twice" or so?
  (maybe not a good example but I guess you know what I mean)

I tried to see what is necessary to do a one-time (or X-time) subscription (see variable subscriptionThreshhold)

// to keep track of subscription and how many times it has been called
let subscriptionThreshhold = 1;
let subscriptionCounter = 0;
let subscription: Subscription = null;
function handleSubscription(data: object) {
    if(subscription) {
        subscriptionCounter++;
        if(subscriptionCounter >= subscriptionThreshhold) {
            subscription.stop();
            // re-init if subscriptions can be done multiple times
            subscription = null;
            subscriptionCounter = 0;
        }
    }
}

// create thing and subscribe
let thing = new ConsumedThing();
subscription = thing.observeProperty("obs", (data) => {
    handleSubscription(data);
});

There might be better solutions. However, even this is not super complex and offers already the possibility to say subscribe 3 times by changing subscriptionThreshhold.

Note: the code snippet is not 100% correct since it does not use promises et cetera.

[zolkis]

Right, so the balance for supporting once is like this:
Pro: convenience
Cons:

• unsubscribe options missing
• multiple subscriptions are complex to implement (this can be solved)
• complexity with different protocol bindings.

Especially the first con looks bad, since introduces corner cases to the app. A convenience most of the time, when other subscribe options are not needed, but when they are needed, it cannot be used, so the app should be aware of what protocol binding is underneath, or otherwise there might be errors difficult to handle.

Occam says get rid of it from this low-level API and let the apps or convenience wrappers implement once.

[zolkis]

Should I close without merging?

[danielpeintner]

@relu91 what is your opinion?

[relu91]

The reason I brought this topic up is that most of the known event APIs support the once option (i.e. Node EventEmitter and EventTarget). Therefore, I thought that developers might expect to have such functionality also inside a WoT runtime. However, I agree that missing unsubscribe parameters might be a problem.

So my final decision would be to drop this feature by now and reconsider later. Maybe when we have a fully stable subscription APIs.

[danielpeintner]

Scripting API Call, 2020-1012:
Decision: No event-API so far... come back after possible subscription API changes

[zolkis]

Closing for now.

[danielpeintner]

FYI: just clicking on the enhancement label does not show this PR (given it is closed).

I created a dedicated issue to not lose track of it, see #274