-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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. |
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! |
I'm afraid that I don't understand the scenario. Could you please exemplify it with a few simple snippets? |
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! |
Why not just return 503 Service Unavailable from the initial subscription request and let the subscription client decide how it wants to follow up? |
Sure, where is the fun in that? Why deny service if we can send them an alternate service in the same request?!! |
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. |
Why I propose this extra complexity is that this would make it identical to the HTTP header negotiation case! |
The situation here is different since the discovery client has already obtained subscription services capabilities. |
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.The text was updated successfully, but these errors were encountered: