Re: Proposal: Adopt State Synchronization into HTTPbis

Most successful internet systems push as much intelligence to the endpoints as possible.  I think that rule applies here too.

For simple subscription use cases, WebTransport suffices, and pushes all relevant logic to the endpoints.  I'm intrigued by the possibility of improving support for continuous synchronization, but adding a complete PubSub system into HTTP itself may ask intermediaries to do more than is necessary.  I would prefer to focus on the minimal functionality we can add to achieve some measurable goal.

One measurable goal is "improve the performance of fanout via HTTP gateways for frequently updated resources".  Specifically, we would like to allow generic HTTP gateways to replicate the resource (unlike WebTransport-based solutions) while (1) avoiding the delays incurred by periodic polling and (2) reducing wasted network activity.

I believe we can accomplish this while staying close to familiar HTTP territory.  For example, we could extend If-Modified-Since (and If-None-Match) with a new parameter, "wait=?1".  When the client sends this parameter, it tells the server to block instead of returning "304 (Not Modified)".  This allows cacheable long-polling for updates, with graceful degradation to short polling if the server/gateway ignores this parameter.  Further optimizations to reduce delay and data transfer can potentially be added on top of this mechanism.

The key distinction between this approach and traditional PubSub is the absence of delivery guarantees.  Allowing slow clients to miss intermediate versions strikes me as essential for compatibility with HTTP's pull-oriented architecture, even though it creates more work for CRDT clients.

--Ben