search

nodeSolidServer / node-solid-server

Solid server on top of the file-system in NodeJS
https://solidproject.org/for-developers/pod-server
Other
1.77k stars 297 forks source link

solid-notifications #1780

Open bourgeoa opened 3 months ago

bourgeoa commented 3 months ago

Objectives : apply solid-notifications protocol https://solid.github.io/notifications/protocol and compatibility with CSS implementation https://github.com/CommunitySolidServer/CommunitySolidServer/documentation/markdown/usage/notifications.md

csarven commented 3 months ago

Objectives : apply solid-notifications protocol https://solidproject.org/TR/notifications-protocol

I suggest implementing: https://solid.github.io/notifications/protocol

  • [ ] discovery subscription service : link header (relative URL ?) link: <.well-known/solid-notifications>; rel="http://www.w3.org/ns/solid/terms#storageDescription"

The reference to storageDescription is essentially same as storage resource's (e.g., the root container, /) describedby resource. So consider using something like </storage-description>.

Resource-centric notification information could also be obtained from a given resource's describedby.

Neither the Storage Description Resource or the Description Resource is limited to notifications information.

  • [ ] unsubscribe : DELETE the subscription url received in the subscription response (no need to be authenticated)

Neither unsubscribe or DELETE is specified in Notifications Protocol.

bourgeoa commented 3 months ago

I suggest implementing: https://solid.github.io/notifications/protocol

done

Neither the Storage Description Resource or the Description Resource is limited to notifications information.

@csarven there is a discussion here https://github.com/zg009/solid-subscription-server/issues/1

Neither unsubscribe or DELETE is specified in Notifications Protocol

Agreed. But CSS felt it was needed. No personal feeling

csarven commented 3 months ago

As you like.

I've already explained why DELETE to unsubscribe is unnecessary in some cases, relatively complicated, and inconsistent with how subscribing works ( https://github.com/solid/notifications/issues/145 ). If folks still want to pursue that path, that's their call entirely.

As for CSS is doing it so NSS should too line of reasoning: keep in mind that decisions in CSS dev is along the lines of "we only implement what's in spec" (which is evidently not true in this and other cases) whenever it is convenient to handwave. On a related note, see also the copyright line. No personal feeling.

zg009 commented 3 months ago

I agree with csarven . I think unsubscribe is unnecessary, especially since an endAt field can be specified by the server and is in spec. endAt doesn't mean you have to stop listening, just you have to open another channel. If a user needs an infinite channel, that could possibly be a separate notifications spec for themselves, or just creating a resource without endTime as a field in the subscription data model.

Edit: It can also be prudent for a server to sleep/end/suspend a channel if it is capable of managing servers.

csarven commented 3 months ago

To be clear, "[u]nnecessary [for some notification channel types]".

And for notification channel types that unsubscribing is useful, it can be accomplished in a similar way to subscribing, i.e., using POST to unsubscribe (as opposed to DELETE).

Any way, this is discussion for the spec space.