Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] PREP Notifications #1785

Open
CxRes opened this issue Nov 21, 2023 · 0 comments
Open

[Feature Request] PREP Notifications #1785

CxRes opened this issue Nov 21, 2023 · 0 comments

Comments

@CxRes
Copy link

CxRes commented Nov 21, 2023

Continuing from our discussion in #1722, this is a formal request to add PREP notifications with Solid-PREP semantics for RDF resources to CSS.

Maintainers could consider adding support incrementally, such as for RDF resources first, and then scaling it to support Non-RDF resources (as the message format is identical to Solid Notifications for RDF resources). Ideally, users should be able to configure which resources provide notifications; the maintainers are better positioned in determining how such a configuration might be provided.


A personal note on architecture: I have previously spoken (in the Solid Chat) on the importance of deviating as little as possible from a REST-ful design in enabling notifications. Notification by definition require servers to persist knowledge about the client, but we can through careful design minimize this information (to only the duration for which a stream should remain open). I would propose that the GET handler only manage the subscription & stream whereas the notification (which could be in a few formats depending on content-negotiation) is generated whenever a write operation (PUT/POST/PATCH/DELETE) occur and be passed on to all of the open GET streams. This way notifications are generated once, rather than being generated for each client. Of course, the downside of this proposal is that notifications cannot be customized for the client beyond content-negotiation. Servers, not the clients, decides properties such as "rate" at which notifications are sent. This is likely to make intermediation easier as well, as an intermediary can predictably amplify notifications. Caveat being that this is a personal opinion and there is no compulsion that implementers to follow this advice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants