Re: [dispatch] Proposal for Per Resource Events Protocol

[Rahul Gupta <[e-mail]>]

Hi Michael,

Replies are spread across posts. A few points of clarification in this one.


Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, August 13th, 2023 at 10:41 AM, Michael Toomim <[e-mail]> wrote:


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

That is true. Except, I have not seen one implementation in the wild do this with SSE (The connection limits issue is a factor for this). Ditto for WebSockets. 

In fact, my first stab at this problem was to define a new media type `multipart/notifications` with its parameters being used for content negotiation (thus not locking a client to `text/event-stream`). But I found that solution does not scale when if we are to define more protocols after PREP.  

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



This is really helpful. PREP operates at level 5 with the change formats defined as separate specifications. See Appendix A where I define one using `rfc822/messages`. I'll be defining one for Solid in the next few weeks, once some issues are resolved with Solid Notifications (the idea being `application/ld+json` notifications will be consistent with Solid). We can easily do the same for mutations as Braid describes (with the benefit that the same would likely work for protocols that supersede/compete PREP).

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

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

I guess our use cases are very much similar, except two caveats:

1.  Clients might want to opt into only notifications without versioning and write mutations (But Braid does not force you to opt-in to those things, so this is a non-issue).
2.  Clients might want to watch creation of new resources/URIs by subscribing to an existing resource (I am not sure how Braid deals with this).

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

Likewise!

> Michael


BR/Rahul