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

Allow channel negotiation to subscription service #191

Open
CxRes opened this issue Feb 3, 2024 · 9 comments
Open

Allow channel negotiation to subscription service #191

CxRes opened this issue Feb 3, 2024 · 9 comments

Comments

@CxRes
Copy link
Member

CxRes commented Feb 3, 2024

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
Copy link
Member

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
Copy link
Member Author

CxRes commented Feb 7, 2024

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
Copy link
Member

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

@CxRes
Copy link
Member Author

CxRes commented Feb 7, 2024

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
Copy link
Member

elf-pavlik commented Feb 7, 2024

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
Copy link
Member Author

CxRes commented Feb 7, 2024

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

@elf-pavlik
Copy link
Member

elf-pavlik commented Feb 7, 2024

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
Copy link
Member Author

CxRes commented Feb 7, 2024

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

@elf-pavlik
Copy link
Member

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.

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

No branches or pull requests

2 participants