- From: Michael Toomim <toomim@gmail.com>
- Date: Sat, 12 Oct 2024 17:38:39 -0700
- To: Ben Schwartz <bemasc@meta.com>, Watson Ladd <watsonbladd@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <809c1951-ce27-49fe-8453-a179d8e2c177@gmail.com>
Very intriguing premise, Ben. Well put!
I very much agree that Long-Polling is a very helpful useful
subscription mechanism that can be supported. Here's how this could look
in Braid-HTTP:
Request 1:
GET /foo
Parents: "1"
After: available (or your header here!)
Response 1:
HTTP/1.1 200 OK
Version: "2"
<body>
...
Request 2:
GET /foo
Parents: "2"
After: available
Response 2:
HTTP/1.1 200 OK
Version: "5"
<body>
...
Request 3:
GET /foo
Parents: "5"
After: available
Response 3:
HTTP/1.1 200 OK
Version: "10"
<body>
I just made up that "After: available" header. It means "don't respond
until after the requested state is available," and the existing
"Parents: <version>" header specifies which version of the state we need
to be available. By updating the Parents: in each request, the client
specifies which update it is waiting for.
If versioning isn't important, a simplified client could just ask for
"After: updated", which will trigger after each update:
Request 1:
GET /foo
After: update (or your header here!)
Response 1:
HTTP/1.1 200 OK
<body 1>
...
Request 2:
GET /foo
After: update
Response 2:
HTTP/1.1 200 OK
<body 2>
...
Request 3:
GET /foo
After: update
Response 3:
HTTP/1.1 200 OK
<body 3>
Long-Polling is a great fallback for any subscription mechanism. It
could get through corporate proxies when necessary. Ben made some great
points about its utility. It is also has a straightforward 1-1 upgrade
path into Symmetric HTTP.
We'd need a header to specify it. I am now tracking three ideas for the
header. Each expresses some variant of "don't respond until X condition":
1. If-Modified-Since: wait=?1 (thanks, Ben)
2. Prefer: wait=4 (thanks, Martin)
3. After: available
I'm not sure how #1 and #2 would wait for a specific version, like I did
in the After: available + Parents: "5" example above. Maybe we add
"wait=available" and "wait=update" to their allowed option values?
I support this. Good thinking.
Michael
On 10/10/24 7:13 AM, Ben Schwartz wrote:
> 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
Received on Sunday, 13 October 2024 00:38:46 UTC