[quicwg/base-drafts] [feature] Push messaging from server to client (#2664)

[Patrick <[e-mail]>]

Hi all,

based on the work we did on https://www.w3.org/Submission/viwi-protocol/ I want to request adding new functionality which can be implemented with two new VERBS and two new headers.

**Use Case:**
Clients want to subscribe to `urls`, as topics with all the filtering, paging information etc. being expressed in the `url`. This would allow services to push information into clients whenever it is considered necessary.

**Implementation:**
As subscriptions are a "convenience" method compared to polling via `GET`, I propose two new HTTP Verbs

* SUB for subscription to `url`
* UNSUB for un-subscribing from `url`

To control the frequency of updates, we would need additional headers:

* subscription-interval: <timeStepInMs> 
* subscription-updatelimit: <timeStepInMs>

_Periodic_
The optional interval attribute specifies the update frequency in milliseconds for periodic updates, while the optional updatelimit attribute specifies the maximum update rate in milliseconds for ‘on change’ notification. If interval is set, updatelimit is always overruled.

_On change_
If interval is not set, the notification interval is defined ‘on change’ and can be limited by specifying an updatelimit. If an ‘on change’ occours before updatelimit elapsed, an event will be sent as soon as updatelimit elapsed. If there are multiple changes before the next possible update, only the last one know state is sent after updatelimit elapsed.

**Summary**
As this is very close to a regular GET, it would be easy and we could also standardise that per each client-server relation, there would just be a single UDP/IP channel for notifications used and held up. We could also specify that this is a "simplex" connection regarding payload data. as clients would use other HTTP verbs to send data. Each data sent from the server to the client would be exactly the same as a GET response. Very straight forward from my perspective and a valuable extension of the standard for all things "realtime". 

All the Headers we replicate in WebSockets today.. puuuffff gone ;) we can just plain HTTP headers... 

The viwi/RSI spec would than be just rewrote to hold the interface design rules etc. the entire WebSocket parts would be obsolete.

Also It would than not be relevant anymore wether we transmit JSON (text) or binary content.. 

Think of it as a GET with multiple responses.. same formats, payloads, everything.. just not req/res but req/res/res/res/res... including all status codes etc.

Re-Auth would also just be another SUB request with a new Token.. super easy ;)


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2664