how to find the Form pair for an operation, e.g. the unsubscribe Form for a given subscribe Form

[zolkis]

Coming from #957 and the need for an algorithm in Scripting PR 264, please identify the mechanism to obtain the Form pair for a given operation.

[danielpeintner]

To make it even clearer. How do you know:

• which unsubscribe matches a given subscribe form
• is there even an unsubscribe?
• is it possible to use unsubscribe on a different protocol (unlikely but e.g., subscribe on HTTP, unsubscribe on CoAP)
• ...

[egekorkan]

I have a feeling that if we want to really solve this properly, we need to explicitly tell the form associated with a form's operation. Something like:

{
//...
"forms": [{
    "op": "subscribeevent",
    "href" : "http://mytemp.example.com:5683/temp",
    "contentType": "application/json",
    "htv:methodName": "POST",
    "unsubscribeevent":{ //this should be probably something else
        "op": "unsubscribeevent", //somewhat duplicate
        "href" : "http://mytemp.example.com:5683/temp",
        "contentType": "application/json",
        "htv:methodName": "DELETE",
}]
//...
}

[zolkis]

I have a feeling that if we want to really solve this properly, we need to explicitly tell the form associated with a form's operation.

I said the same in the Scripting call, i.e. either link/reference/index the unsubscribe Form, or specify them as a tuple.
The former would be an extension of the current model, the second would be a breaking change.

[sebastiankb]

I like @egekorkan proposal. Maybe this can be also a direction that can be used for the topic with hypermedia #899

[zolkis]

Perhaps instead of unsubscribeevent field in the parent Form we could use a generic cancel field for operations, which in this case would be a Form with op: unsubscribeevent.

[relu91]

Just stumble again on this issue while implementing the new ConsumedThing subscription API for node-wot: eclipse-thingweb/node-wot#585. In my opinion, the only viable solution to make a clear and consistent algorithm is @egekorkan's proposal, to have a pair of subscribe/unsubscribe forms.

IMHO, this feature is currently pretty broken cause a consumer would have a hard time understanding the right form to use once it has a subscription already in place. For TD 1.1 we can introduce a new keyword to at least stem the issue, but probably a more consistent approach might be beneficial to solve also the new Action model.
Another option would be to allow unsubscribe operations only in op arrays with its counterpart (i.e. subscribeevent or observeproperty).

@egekorkan @sebastiankb can we add this issue to the next agenda? should it be deferred?

[egekorkan]

Better to defer it I think since this is indeed a discussion requiring issue. Regarding requiring them as pairs in an op is that if I do mqv:controlPacketValue when op is an array, to which op does it correspond to? It is obvious to us humans but how can a machine understand that mqv:controlPacketValue:subscribe corresponds subscribeevent part of the op array and not unsubscribeevent

In any case, it is a rather interesting issue and treating subscriptions the same way as handling actions seems like a usable idea. In the end, cancelling an action can be considered analogous to unsubscribing from an event

[relu91]

In any case, it is a rather interesting issue and treating subscriptions the same way as handling actions seems like a usable idea. In the end, cancelling an action can be considered analogous to unsubscribing from an event

Indeed, in the Scripting API we were discussing to use the same interface for both Subscriptions and async Actions, there definitely a pattern. I could factor out something 🤔 .

[benfrancis]

@danielpeintner wrote:

• which unsubscribe matches a given subscribe form
• is there even an unsubscribe?

I guess this depends on the protocol or sub-protocol being used.

For Server-Sent Events an unsubscribe operation just involves dropping the open connection that was created in a subscribe operation. In this case the Consumer doesn't really need to look for a Form at all since it's implicit in the protocol. E.g. For the unsubscribe operation in the Core Profile we just say to "terminate the corresponding Server-Sent Events connection", rather than look up an endpoint in a form. (For JavaScript Consumers, the EventSource JavaScript API has an explicit close() method for this purpose).

The same is probably true for long-polling where an unsubscribe operation involves dropping an open connection (or not reconnecting it when it times out).

For WebSub, the subscribe and unsubscribe operations use the same HTTP endpoint and verb, with subscribe or unsubscribe mode set as part of the payload.

For WebSockets it would be inefficient to use a separate socket for each event subscription and unsubscription, so in that case an existing open connection is also likely to be used for an unsubscribe operation, with a message format defined in a subprotocol. (It's still not entirely clear how to define a protocol binding for WebSockets which re-uses a connection between all operations though.)

In general if there's only one form for an unsubscribe operation using the same protocol as a form for the subscribe operation then it's probably quite straightforward to determine which to use, but if there are multiple forms for the same operation using the same protocol then I agree there could be cases where it's ambiguous.

This seems like a specialised case of the more general problem of how a Consumer should select from multiple forms for any given operation, for which there isn't currently any specific guidance in the specification. I've proposed "Define an algorithm for parsing a Thing Description" as a potential deliverable for the next charter in order to resolve these kinds of ambiguities.

• is it possible to use unsubscribe on a different protocol (unlikely but e.g., subscribe on HTTP, unsubscribe on CoAP)

Eesh, yes that does get complicated.

[danielpeintner]

To me, what is missing is a clear information in the TD on each observe about

• what is (are?) the right form(s) for each subscribe to unsubscribe
• is there any unsubscribe at all?

[egekorkan]

I am adding v1.1 since we can at least add an informative warning-like text

[sebastiankb]

from today's TD call:

• node-wot allows to use different protocols, eg., to subscribe via CoAP and to unsubscribe via HTTP
• however, it seems a more edge case
• it would be also good to hear the view of @mlagally
• principal, it should be re-discussed in the next version again (maybe is solved then by the new idea of the new connection container; also see Describing initial connection #878)