Solid WebSockets API: Missing Unsubscribe!

[CxRes]

How does one unsubscribe to watching a resource without terminating the websocket connection itself?

[MasterJames]

Try reviewing this maybe?
https://github.com/solid/solid/issues/70

[CxRes]

@MasterJames I am a bit confused by your comment!

Do you:
a) believe that I can find an answer in solid/solid#70?
or
b) want me to suggest improvements, like others in solid/solid#70?

[MasterJames]

Maybe a little from column A (not knowing the state of affairs) and a little from column B (if it is not working properly in the latest builds, or yes to add comment/feedback to the ideas [? If what sould be obvious is not] to your liking or before it gets more engrained if not fully happening yet).
I guess I dont know much I had assumed if you can subscribe you can just unsubscribe?! My appologies if this is not working nor documented yet, (and you'd get a long ponderous pause and a truly disheartened sigh if things were left hlf bakd like that.)

[CxRes]

I have looked the spec and the NSS code!

The WebSocket API needs a unsubscribe call!

[Ryuno-Ki]

I think, a naive API would be to return a function of the subscribe call which allows to unsubscribe.
You can see similiar behaviour with setTimeout or RxJS subscriptions.

However, the removeListener API for Socket.io looks a bit different.

[CxRes]

IMHO you do not need a complicated API here. Whatever the API, the server will ultimately need to see a message on the websocket (since the socket only carries messages), something of the form unsubscribe <url>. We might as well have the client send that directly on the Websocket.

[csarven]

Moving this issue to solid/specification for consideration.

[csarven]

Related:
https://github.com/solid/specification/issues/155
https://github.com/solid/specification/issues/168

[elf-pavlik]

I believe that the current draft defines unidirectional notifications. The resource is specified as topic during subscription and all the further communication is unidirectional.

When it comes to unsubscribing, I see why it is needed for subscription types where the publisher delivers a notification to target specified during the subscription step.

For subscription type where subscriber connects to notifications source, closing connection seems sufficient. Why do you see the need for specific unsubscribe request?

[elf-pavlik]

@CxRes can we close this issue and pick it up in #145

[CxRes]

@elf-pavlik The only reason I am reluctant to close this issue is that there are items linked here (see links brought in by @csarven here and in turn in those issue), which form a tangled web. I am happy to continue discussion in #145 and keep the discussion in one place, but I propose closing this along with #145,