search

solid / notifications

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

Allow channel negotiation to subscription service #191

Open CxRes opened 5 months ago

CxRes commented 5 months ago

Solid Notifications should allow a subscription request with multiple channels (with priority indicated, say, by q values), such that a service can return a preferred notification channel based on its capabilities.

elf-pavlik commented 5 months ago

We discussed it and decided that since this practically works as Reactive Negotiation, the client will know exactly what the server supports and can make a subscription request that the server will support.

CxRes commented 5 months ago

Primarily not for that purpose! This allows a client to indicate a preference between two available channel options (to provide a better degradation of service when a server is unable to temporarily create the preferred channel)!

Though it could also be the case (unlikely, not impossible) that a subscription service is communicated out of band by a trusted source. That could turn it into a proactive negotiation like scenario!

elf-pavlik commented 5 months ago

I'm afraid that I don't understand the scenario. Could you please exemplify it with a few simple snippets?

CxRes commented 5 months ago

Imagine a case that you, the client, requests a WebSocket2023 channel (which is advertised by the description resource), but the subscription service cannot recreate it because behind the scenes WebSocket channel provider is unable to manage a temporarily high demand. So now, instead, you will make a second request for a HTTPStreaming channel. That preference can potentially be combined into one request!

Snippets wise, it will be an array of objects instead of one object in subscription request, with an extra 'q' property!

elf-pavlik commented 5 months ago

Why not just return 503 Service Unavailable from the initial subscription request and let the subscription client decide how it wants to follow up?

CxRes commented 5 months ago

Sure, where is the fun in that? Why deny service if we can send them an alternate service in the same request?!!

elf-pavlik commented 5 months ago

We should not add complexity to the spec to avoid an extra HTTP request in cases where a part of the subscription service becomes temporarily unavailable. As I understand your proposal, it only works where the same subscription service supports multiple channel types; in that case, the subscription client would even make the follow-up request over the same connection, assuming HTTP/2.

CxRes commented 5 months ago

Why I propose this extra complexity is that this would make it identical to the HTTP header negotiation case!

elf-pavlik commented 4 months ago

The situation here is different since the discovery client has already obtained subscription services capabilities. Would you like to create a PR that includes all the normative requirements to evaluate added complexity better? This way, we can better assess the expected impact on implementations.