search

solid / notifications

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

Quick Notifications #192

Open CxRes opened 5 months ago

CxRes commented 5 months ago

Solid Quick Notifications is a proposal to use Accept-Events and Events header fields that I invented in PREP to allow Clients to negotiate subscriptions i.e. request a notification channel, using a mechanism identical to content negotiation in HTTP. With this one can request a notification channel in a single request, and given that a client will anyway start with a GET request to the topic, the subscription step is effectively free when using proactive negotiation. While not as efficient as PREP over a single topic, this would outperform it when requesting notifications for multiple topic resources.

For public channels, I am proposing to introduce a Notification-Channels header field to, well, advertise the channels.

I believe this proposal solves all the issues raised by @TimBL in #110 as well as the concern he raised in the notification panel meeting on 12-01-2023 while remaining completely backwards compatible (apart from an extremely minor caveat) with Solid Notifications. One can even use it alongside the existing specification, providing clients a choice of mechanisms for discovery and subscription of notifications.

Updated HTML Preview | Diff with main branch | Diff with backported changes to SNP

CxRes commented 5 months ago

@csarven This is to start a conversation. My long term suggestion (especially if such a work can get funded), is to reorganize Solid Notifications in a number of specifications:

Really, the bulk of work has to be done in the last two! It also makes it easier for someone entering Solid Notifications to work with more palatable chunks! This might be a good opportunity to rebrand as well, Since these notifications can easily be used outside Solid.

csarven commented 5 months ago

Can we take this up in an STM? I'd like to understand better whether this should be incorporated into SNP or being proposed as a new work item or what...

.. In addition to noting any early commitments for implementation.

CxRes commented 5 months ago

First and foremost, I would like for the reviewers to verify if my proposal is functionally correct!

We can decide then how to proceed, an extension, an independent work item or re-organization of notification specs. I think all three are viable, but it is really a question of resources and participation.

I would like an STM as well, perhaps after a first round of reviews!

CxRes commented 4 months ago

@TallTed Great Start!!! Thanks for detailed review. I have accepted (and backported) most of your suggestions. The only changes that I have not accepted have to do with <li> punctuation, which I will revisit later.

@csarven Can you please look at Conformance section suggestions made by Ted (since these are really fixes to SNP). If you agree, I will merge them in and backport them to protocol.html.

CxRes commented 4 months ago

@TallTed Thanks again! These batch of changes I was (mostly) aware of, but did not make them because they apply to the main protocol itself!

Having said that, I will accept them and backport them to SNP (sometime, next week, though).