Re: [dispatch] Proposal for Per Resource Events Protocol

[Michael Toomim <[e-mail]>]

On 8/14/23 3:45 AM, Rahul Gupta wrote:
> Since mutations can differ for the type of resource, imho it is best to provide a negotiation mechanism instead. Which is what I do in PREP. Intermediaries can then handle mutations as they handle representations.

This might be hard to believe at first, but there actually exists a 
universal format that can express any mutation to any resource. We call 
this format the Range Patch 
<https://raw.githubusercontent.com/braid-org/braid-spec/master/draft-toomim-httpbis-range-patch-01.txt>, 
and it expresses any change as:

    "The range X specified in units Y was replaced with new contents Z."

The existence of this universal mutation format is a big deal, because 
it means a LOT less needs to be customized or specified for any 
particular application. All you need is a Range Unit 
<https://www.rfc-editor.org/rfc/rfc9110#name-range-units> that matches 
your resource's Content-Type.

Furthermore, Range Units are already things defined by HTTP, for Range 
Requests <https://www.rfc-editor.org/rfc/rfc9110#range.requests>. And 
now that HTTP supports Ranges inside of a PUT (called "Partial PUT 
<https://www.rfc-editor.org/rfc/rfc9110#name-partial-put>"), it has a 
built-in universal patch format.

That means that a universal patch format is already built into HTTP. 
This is enough to support all CRDT/OT operations in use today, and any 
other mutation I've run across.

All we need to do is specify the Range Units for our resources. Today, 
there's only a single range unit that's ever been standardized— the Byte 
Range <https://www.rfc-editor.org/rfc/rfc9110#name-byte-ranges>. We just 
need a standard JSON range, and one for whatever other content-type you 
care about — .PSD files, or whatever.

I suspect we can get into more of this in our upcoming call!

Michael