Re: Proposal: Adopt State Synchronization into HTTPbis

Hi Asbjørn,

Thanks for the upvote. Some specific responses below.

On Friday, November 1st, 2024 at 5:17 AM, Asbjørn Ulsberg <asbjorn@ulsberg.no> wrote:

> 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.

Given its election season in the US, quoting JFK seems weirdly appropriate :)

> 

> 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.)

As I had discussed in my presentation at IETF118 in Prague, extending SSE is not an option because WHATWG has abandoned EventSource/SSE. This was a part of the reason I bothered writing up a new protocol in the first place and bring it to HTTPWG/IETF. When working on Solid Notification Protocol (a separate effort from PREP), we also found a community preference for adopting streaming HTTP over SSE. FWIW, notifications are better solved as a proper extension to HTTP, rather than as a browser API. WHATWG was never the right home for SSE (in my judgement).

But now that I have taken the effort to write up a new protocol, rather than just tack on pub/sub in the easiest way possible, I believe it is only prudent to extend HTTP superpowers of REST, particularly content negotiation, to the time dimension (Call it RESS, RESync, whatever else you fancy). Anything less is a waste of a golden opportunity for short-sighted gains (and not much better than using WebSockets, WebTransport etc.). After all, it is HTTP Semantics (a.k.a. RFC9110) that we are leveraging for notifications. I am happy to look at "application/http", a new media type or a new mechanism such as the proposed QUERY method, provided they are consistent with demands 1 and 2.   


> 

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

BR/Rahul