search

solid / notifications

Solid Notifications Technical Reports
https://solid.github.io/notifications/protocol
MIT License
11 stars 7 forks source link

Solid WebSockets API: Missing Unsubscribe! #6

Open CxRes opened 4 years ago

CxRes commented 4 years ago

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

MasterJames commented 4 years ago

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

CxRes commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

I have looked the spec and the NSS code!

The WebSocket API needs a unsubscribe call!

Ryuno-Ki commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Moving this issue to solid/specification for consideration.

csarven commented 4 years ago

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

CxRes commented 4 years ago

@csarven I am seeing that there are a bunch of issues dealing with different ideas all related to the WS implementation. Is there some common space we can collate these suggestions (not the issues but the ideas stated there) moving forward? Its quite a pain having to navigate away and lose context!!!

csarven commented 4 years ago

@CxRes Let's continue this kind of discussion in chat: https://gitter.im/solid/specification?at=5ea2993661a0002f7946bf13 or in the spec meetings.

elf-pavlik commented 2 years ago

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 commented 1 year ago

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

CxRes commented 1 year ago

@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,