Re: Proposal: Adopt State Synchronization into HTTPbis

On 9 Oct 2024, at 18:50, Watson Ladd <watsonbladd@gmail.com> wrote:

> We have (c): it's called WebSockets. What isn't it doing that it
> should be?

WebSockets (and WebTransport) are low-level, complex, and separated from HTTP. SSE is simple, and built on the protocol we all know and love. I think it’s worth trying to build something similarly simple to SSE, but for two-way state synchronisation, using the familiar semantics of HTTP.

> I'm sympathetic to fixing the foundations but there's lots of
> complexity here that hasn't been addressed, and IMHO makes the
> juice not worth the squeeze.

"We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one we intend to win, and the others, too.”

;-) Please excuse the quote and tounge-in-cheek, but seeing how this problem domain has existed since XMLHTTPRequest was first invented and no satisfying standards-based solution still exists, I think that if anyone are going to figure out a solution, it’s the participants of the IETF HTTP WG. We should try to solve it precisely because it is a difficult problem to solve.

On 15 Oct 2024, at 12:09, Rahul Gupta <cxres@protonmail.com> wrote:

> The fact that various people have taken stabs at this problem now
> for 25 years at a minimum serves as social-proof for the interest
> in using HTTP to serve notifications. 

Yep, that’s my conclusion as well!

> The ability to consume (representation and) notifications with just
> half a dozen lines of code is for clients rather compelling. (I might
> be wrong, but I am actually not sure if browsers even need to be
> modified here at all).

I’m having the same thought. If this mostly comes down to keeping a connection alive and manipulating headers, browsers could be none the wiser about exactly what’s going on. A thin wrapper on top of `fetch` could perhaps suffice.

> 1. The protocol MUST be consistent with HTTP: It should go without saying but a baseline notification protocol has to be consistent with the specification. I would also prefer that it minimally extend HTTP and with minimum upgrades to deployed infrastructure. 

+1

> 2. The ability to negotiate different notification protocols: I, for one, do not believe there is a one true protocol; and that we must have the humility to accommodate different solutions (a baseline protocol means subsequent solutions will also have more opportunity to experiment). Negotiation of protocols (whether explicit or automatic) also opens up the possibility to craft solutions that are (to Mark’s point) specific to H2/H3 that can take advantage of native framing, and provide a graceful downgrade path for HTTP/1.1 (which imho is better than not having a notifications solution for HTTP/1.1 at all).

Sounds reasonable. +1

> 3. The ability negotiate the media-type of notifications

Perhaps? If we take a look at the following paragraph from the BRAID draft:

> …but SSE provides semantics of an event-stream, not an update-stream, and
> SSE programmers must encode the semantics of updating a resource within the
> event stream. Today there is still no standard to push updates to a
> resource's state.

…perhaps we could get away with defining “a standard to push updates to a resource’s state” over SSE? While I really like the elegance of PREP’s per-resource event stream principle, I think the implementation details around multipart is a bit complicated, but more importantly: SSE is already here. And besides the intermediary problems mentioned by Mark, it works. (I believe the mentioned problems will apply to most protocols we come up with trying to solve state synchronisation.)

-- 
Asbjørn Ulsberg.         -=|=-         asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»

Received on Thursday, 31 October 2024 23:47:56 UTC