Re: [dispatch] Proposal for Per Resource Events Protocol

[Rahul Gupta <[e-mail]>]

Dear Michael,

I was made aware of the Braid proposal by TimBL in a Solid OS meeting in the summer. And while there is considerable interest in implementing CRDT/OT in the Solid community, I have unfortunately very little knowledge of that.

Further responses interleaved in the original message.

------- Original Message -------
On Wednesday, August 9th, 2023 at 2:48 AM, Michael Toomim <[e-mail]> wrote:


> On 8/8/23 1:21 PM, Dale R. Worley wrote:
> 

> > Looking at that web page, ... it doesn't provide a clear summary that the
> > naive reader can read to grasp the big picture (and then fill in the
> > details reading the rest of the text).  Put something like your "How it
> > works" at the top.
> 

> I would really like to see some example use-cases for it, along with scenarios showing how this meets those use-cases.
> 

> 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. In PREP, you GET an any existing resource and the response contains notifications. This is great for POD storage where I might upload, say, a document and when I change it you get changes if you have placed a GET on that document. In case there is another document, you can place another GET on that.

Since the documents on your PODS can change, with SSE you will need to have a separate endpoint that will aggregate changes to documents that a client is interested in and dispatch them to the subscribing client who has to disaggregate these changes for each document (we do exactly this using WebSockets and StreamingHTTP in Solid Notifications Protocol, SSE itself is too limited). 

Further, SSE specifies a format (media-type) for notifications. PREP lets you use any format for notifications. 

> And Rahul, I'm actually planning to dispatch a very similar proposal in Braid this November. Depending on the overlap in use-cases you are trying to support, we might end up being able to combine our efforts. 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.
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.

BR/Rahul