Re: [dispatch] Proposal for Per Resource Events Protocol

[Michael Toomim <[e-mail]>]

Rahul:

> *Michael, would you be open to 15-20 minute call? I can both explain 
> myself and understand from you how Braid works a bit better.*
Yes, definitely! It's a pleasure to meet you! I spoke with Tim 
Berners-Lee this summer, and he got me excited to integrate Braid 
subscriptions with Solid as well. Let's definitely set up a call and 
make some stuff work!

>> It's not clear to me how Per-Resource Events differs from SSE, for 
>> example.
>>
> In SSE, you dedicate a resource as endpoint for notifications.
>
I agree that it's better to use a single endpoint for state and its 
notifications. Braid-HTTP does this too. However, to be fair to SSE, it 
/does/ support a single URL for both state and its updates. SSE requests 
are distinguished by the `Accept: text/event-stream` header, which means 
you can overload every URL in your app with an SSE notification stream 
for it by looking for that header.

On the other hand, SSE /does/ require two requests per resource here— 
one to GET the resource, and another one to get the updates. It's nice 
to reduce this to a single request, and Braid-HTTP does this too.

You can see an example Braid-HTTP request in the Subscriptions section 
here: 
https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http#section-3

First it returns the current state of the resource, and then the 
connection is left open, and it streams updates to the resource that 
have occurred since it was first returned.

>> Braid supports per-resource events that describe *mutations to 
>> state.* I would be curious to learn if you have use-cases for events 
>> beyond mutations to state.
>>
> I am not exactly sure of what you mean by "mutations of state", but 
> messages are sent in PREP typically when an HTTP operation occurs, 
> like PUT or POST (these can be redefined for a media-type, see 
> Appendix A). For example, POST might not change the current resource, 
> but create another resource. Still, a notification might be sent for 
> the resource/URI where POST was done.

Here's what I mean by "mutations of state":

    Backgorund: REST stands for REpresentational State Transfer. Each
    URL has state. When the state of a URL changes, that is a mutation
    of state.

Now, there's a hierarchy of specificity that an HTTP event stream 
specification might operate at:

 1. Byte stream: A stream of bytes to be parsed (e.g. TCP)
 2. Event stream: A stream of discrete separate events, possibly with
    event IDs (e.g. SSE, WebSocket)
 3. Pub/sub stream: A stream of pub events that can be subscribed to
 4. Mutations: Subscribing specifically to changes to the resource's
    state (e.g. Braid-HTTP)
 5. Formatted mutations: Subscribing to mutations expressed in a
    particular change format (e.g. Braid-HTTP w/ Range Patch)

Braid-HTTP is specifically designed to express levels 4 and 5: mutations 
to state. These are by far the most common use-case for event streams, 
and it's important to have a standard for them. Otherwise, we end up 
with a standard that's not very useful for interoperability in real web 
apps. MNot describes some of this here 
<https://www.mnot.net/blog/2022/02/20/websockets>.

I've been curious if PREP is trying to address any use-cases for event 
streams /beyond/ mutations of state. If not, then we should merge our 
efforts (and I'll advocate for operating at level 5). If so, I'd love to 
hear what the use-case is, to know what Braid-HTTP isn't handling.

Any PUT request /is/ a mutation of state. A POST request usually creates 
or mutates state, and you can subscribe to the resulting mutation with 
Braid-HTTP, too. So I suspect that we are tackling the same use-cases.

I am very glad that we're getting connected. Thanks a bunch of taking 
initiative on this important work!

Michael