[T2TRG] Fwd: Mnot's Pub/Sub for the Web

[Carsten Bormann <[e-mail]>]

You may want to follow the below discussion in the httpbis WG.

> Archived-At: <https://www.w3.org/mid/[e-mail]>

The threading on that mail archive is a bit clumsy, but I’m sure the thread will be interesting.

Grüße, Carsten

> Begin forwarded message:
> 
> From: Michael Toomim <[e-mail]>
> Subject: Mnot's Pub/Sub for the Web
> Date: 2022-02-20 at 10:36:33 CET
> To: HTTP Working Group <[e-mail]>
> Cc: Mark Nottingham <[e-mail]>
> Resent-From: [e-mail]
> Archived-At: <https://www.w3.org/mid/[e-mail]>
> Message-Id: <[e-mail]>
> 
> Hello, HTTP!
> 
> Today Mark Nottingham posted a great articulation of the issues programmers face when choosing between using SSE, WebSockets, and WebTransports:
> 
> https://www.mnot.net/blog/2022/02/20/websockets <https://www.mnot.net/blog/2022/02/20/websockets>
> I'll attempt to summarize Mark's beautiful insight as: in almost all cases, what the programmer *really* wants is a Pub/Sub protocol, not an arbitrary socket. And we could standardize a Pub/Sub protocol, and that would have great benefits.
> 
> These benefits are real and I think could improve performance dramatically. CDNs could cache realtime updates, not just static data.
> 
> However, I'll take Mnot one further, and propose that when a programmer is choosing a Pub/Sub protocol, what he *really* wants is a State Synchronization protocol, not an arbitrary Pub/Sub protocol.
> 
> He wants to Subscribe specifically to *state updates*. He wants to Publish specifically *updates to state*.
> 
> What we need is not a general Pub/Sub standard, but specifically a State Synchronization standard. State Synchronization is a constrained type of general Pub/Sub. And we'll need to constrain Pub/Sub in this way to address some of the issues Mark brings up, such as:
> 
> > There are also some architectural/philosophical concerns about how non-final responses **relate to the state of the resource**.
> 
> The relationship between a server's "responses" and the "state of the resource" is what a State Synchronization protocol defines. And, in fact, we have two proposed solutions to State Synchronization in the IETF!
> 
> Braid:         https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http <https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http>
> Mercure:    https://datatracker.ietf.org/doc/draft-dunglas-mercure/ <https://datatracker.ietf.org/doc/draft-dunglas-mercure/>
> I am seeing a growing awareness that HTTP needs to add State Synchronization abilities, as well as excitement about the new fundamental power it gives programmers on the web.
> 
> 
> These protocols transform HTTP from a State *Transfer* into a State *Synchronization* protocol. Whereas a transfer protocol can move a resource from server to client in a single request/response, it requires an application programmer to take over if the resource ever changes after the response completes. That sucks for programmers. A synchronization protocol provides a much better programming abstraction. The programmer just says "I want state X", and can assume it will be kept up-to-date by the protocol.
> 
> If we standardize this, we also get CDNs that automatically cache dynamic content (the stuff currently hidden within websockets), just as easily as they cache static content today. We get collaborative editing and offline modes available in web apps for free. We also take an important step towards decentralizing the web, by creating an open standard for the trickiest part of decentralized app development — data synchronization — that is compatible with P2P CRDT and OT algorithms.
> 
> Since this all seems to be coming together, I would like to know what HTTPbis as a group thinks. Is there interest in this topic?
> 
> If so, what aspects might we want to work on?
>