New Versioning Spec!

[Michael Toomim]

Hey guys, I've drafted a new spec specifically for versioning:

https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-versions

I'd love to get feedback!

This draft takes our existing Braid-HTTP versioning spec and adds:

• An introduction comparing it to the existing versioning schemes in HTTP
• A first description of a Version-Type: header. Braid software is starting to need this!
  
• A new idea for subscription framing — called Multiresponse
• A whole slew of new examples, to illustrate all the places versioning can be useful in HTTP!

I did this work in response to last fall's IETF feedback:

"You need to break the Braid-HTTP spec up into multiple specs, and work bottom-up. IETF is very 'bits-on-the-wire' minded. Low-level and concrete."

So I thought that versioning was the place to start. It's a low-level, modular, independent chunk that lots of systems can use.

You will shortly see an email initiating conversation with the HTTPWG. Please direct substantive comments there!

Michael

[Peter van Hardenberg]

Hi Michael,

I had a quick look at the spec and gave some thought to whether we'd want to adopt it. I think right now it has quite a lot of per-version overhead, and viewing this through a local-first lens, one can imagine having to publish a large number of versions each as separate PUT calls. You might want to consider supporting ranges for PUT in a single message.

Overall, our goals appear to differ from what you're proposing here so this feedback may not be particularly important. My sense is that the expected granularity of changes for Braid is relatively large and that the frequency is relatively long -- on par with a changed HTML form submission, perhaps. We spend quite a lot of our time thinking about optimizing updates for potentially thousands of edits and trying to minimize the number of round trips required to synchronize state in both directions. You mention that the design intends to be optimizable but I didn't see much in the text that clarified how. 

One other observation is that this spec does not appear to prioritize retention of history: 

>      - If the Parents header is absent, the server SHOULD return a

>      single response, containing the requested version of the resource
>      in its body, with the Version response header set to the same
>      version.

This design may centralize the system, as clients default to receiving "flattened" versions of resources and thus may not be able to merge changes from other sources.

Last, have you considered specifying some kind of signature / validation feature? If clients are applying patches iteratively, it might help for them to be able to validate that they're in the expected state either before or after applying a patch.

All the best,

-p

--
You received this message because you are subscribed to the Google Groups "Braid" group.
To unsubscribe from this group and stop receiving emails from it, send an email to braid-http+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/braid-http/518f842b-928c-4446-ae29-cea4ea80aa26%40gmail.com.

--

Peter van Hardenberg
"Everything was beautiful, and nothing hurt."—Kurt Vonnegut