search

solid / notifications

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

Proposed optimization when using StreamingHTTP channel #164

Open CxRes opened 1 year ago

CxRes commented 1 year ago

This proposal attempts to solve #110, that is, to allow clients to start receiving notifications in a single request-response cycle (at least in the case of Streaming HTTP), while preserving the essential generality of the Solid Notifications Protocol for other channel types.

I propose that Subscription Clients, when requesting a subscription using HTTP based notification channels (specifically Streaming HTTP channel, but possibly others in the future), may request the Subscription Server to start streaming notifications immediately instead of sending back a cURL. In other words, the Subscription Server also automatically acts as a Notification Sender.

The proposal takes advantage of the fact that Subscriptions are negotiated over HTTP and notifications are sent over HTTP as well. In the case of other channels, one needs to use cURL to establish the notification channels in another protocol. Since we are not switching protocols with streaming HTTP, this step becomes optional.

This proposal will work as an optional notification feature, say, instantConnection. That is, the Subscription Service, through the Discovery mechanism, can advertise whether a given subscriptionType supports this feature, and clients can request this feature. The response from the Subscription Server will be of the form of Notification Channel Data Model, followed by zero or more Notification Message Data Model.

CxRes commented 1 year ago

@csarven (I am sure he will correct me 😃) has suggested that when using instantNotifications, startAt MUST not be specified and is assumed to be immediate. I think this is a case of idiot proofing, but I recognize that such idiot proofing might be necessary to prevent clients from opening streams that are only meant to be used hours or days later.

csarven commented 1 year ago

No, I was sharing an interpretation, not a solution, during the 2023-03-16 meeting: there seemed to be some overlap between instantNotification and startAt (or lack thereof - which is intended to be now/ASAP.)