ObserveProperty with uri vars

[ferllings]

Hello,
Could someone clarifies something for me?
In the ObserveProperty method: https://w3c.github.io/wot-scripting-api/#the-observeproperty-method

This algorithm allows for only one active Subscription per Property. If a new Subscription is made while an existing Subscription is active the runtime will throw an NotAllowedError.
And #6 confirms
If thing.[activeObservations][propertyName] [=map/exists], [reject] promise with a [NotAllowedError] and stop.

But in the case of using uriVars, do we consider the subscription is the same, even if the uriVars are different?

#8 indicates:

Make a request to the underlying platform to observe the [Property] identified by propertyName with form and optional URI templates given in options' uriVariables.

What if we already made a previous request, .../propertyA?v=X
but we want to make a new request for .../propertyA?v=Y

And I believe there is a mistake in subscribeEvent() https://w3c.github.io/wot-scripting-api/#the-subscribeevent-method
#6 says

If thing.[activeSubscriptions][eventName] DOES NOT exist, reject promise with a [NotAllowedError] and stop.

Thanks for your help?

[relu91]

And I believe there is a mistake in subscribeEvent() https://w3c.github.io/wot-scripting-api/#the-subscribeevent-method
#6 says

If thing.[activeSubscriptions][eventName] DOES NOT exist, reject promise with a [NotAllowedError] and stop.

Related to #540 .

For question, yes with the current approach, you can't have two active subscriptions to the same Event. This means that if you need it you have two options:

1. you subscribe and then unsubscribe and then subscribe again
2. You consume the Thing twice and then use the second instance to subscribe with the new URI variables

I know that both options are not ideal, we can work to fix this issue in the future release. To understand better it would be valuable if you provide a short description of the concrete use case you have ( protocol you are using, platform, etc.? ).

@zolkis: it is a bug since a subscription without, or with [different] URIVariables should be considered different subscriptions, made with different requests. So we need to address this in the spec.

[ferllings]

@relu91 Thanks for the clarification
For the context, I'm running my own golang implementation of WoT, for home automation.
It only supports http/ws for now.

I have a (thing) service that provides some dynamic states for my house.
And clients that observe those states, using filters to trigger various automations.
something like /isAtHome?name=me or /isAtHome?name=wife

I'll find a workaround, until this get clarified in the next version