Re: [dispatch] Proposal for Per Resource Events Protocol

[Tim Bray <[e-mail]>]

 Haven’t been following this that closely, but just thought I should
mention, in case nobody else has, CloudEvents (from CNCF, Cloud Native
Computing Federation, best-known for k8s): https://cloudevents.io/

While I was working at Amazon I led the design and implemented lots of
parts of a product called EventBridge, which has been very successful for
AWS: https://aws.amazon.com/eventbridge/

Which is to say, there’s quite a bit of existing state of the art here that
could possibly be re-used. I can testify from personal experience that
event streams are in practice super useful.  Attaching this idea to the
Web’s notion of a resource seems like a good idea.


On Aug 12, 2023 at 10:11:29 PM, 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.
>
> 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
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>