3 ms·

They seem to have made a choice that URL's do not include version numbers. Instead, the version is sent as a separate header. That would make it hard to link to

They seem to have made a choice that URL's do not include version numbers. Instead, the version is sent as a separate header. That would make it hard to link to a specific version. I suppose there's nothing stopping anyone from also having URL's for specific versions, but it's not standardized. More generally, I'm unconvinced that synchronization should be so closely tied to HTTP, or that the metadata should be independent of the actual datatypes being synchronized. Any given application is going to need to implement not only a synchronization algorithm, but the datatypes being synced. Contrast with git, where the data is standardized (file, directories, commits) and it supports many ways of communicating about the data. (Though, at another level, git doesn't care what's in a file, and that's also true of HTTP.)

toomim 2y ago
Yes, we will want to extend URLs to standardize an optional version identifier. It's important for this to be optional. Consider that each keystroke that edits a text resource changes its version ID. You want to be able to link to the text without changing the ID with each keystroke. It's also important to be able to pass versions within headers of a request or response. The server wants to update the version ID with each update it sends to the client, and that's most elegantly done in a header. As for your skepticism about integrating synchronization into HTTP instead of embedding it within a datatype, I can empathize -- but you might be surprised at just how elegantly HTTP extends into a full-featured synchronization protocol. A key to this elegance is the Merge-Type: this is the abstraction that allows a single synchronization algorithm to merge across multiple data types. As an application programmer, you will specify both the data types of your variables (e.g. int, string, bool) and also the merge-types (e.g. "this merges as a bank account balance, or a LWW unique ID, or a collaborative text field"). This is all the application programmer needs to specify. The rest of the synchronization algorithm gets automated by middleware libraries that the programmer can just use and rely upon, like his compiler, and web browser. I'd encourage you to check out the Braid spec, and notice how much we can do with how little. This is because HTTP already has almost everything we need. Compare this with the WebDAV spec, for instance, which tries to define versioning on top of HTTP, and you'll see how monstrous the result becomes. Example here: https://news.ycombinator.com/item?id=40481003 https://news.ycombinator.com/item?id=40481003
- skybrian 2y ago
  Thanks. Yes, that's a much more fine-grained use of versioning than we use in git repositories. I suppose this sort of synchronization is more like a streaming protocol than a version-control system. (A stream of updates.)

toomim 2y ago

Yes, we will want to extend URLs to standardize an optional version identifier. It's important for this to be optional. Consider that each keystroke that edits a text resource changes its version ID. You want to be able to link to the text without changing the ID with each keystroke. It's also important to be able to pass versions within headers of a request or response. The server wants to update the version ID with each update it sends to the client, and that's most elegantly done in a header. As for your skepticism about integrating synchronization into HTTP instead of embedding it within a datatype, I can empathize -- but you might be surprised at just how elegantly HTTP extends into a full-featured synchronization protocol. A key to this elegance is the Merge-Type: this is the abstraction that allows a single synchronization algorithm to merge across multiple data types. As an application programmer, you will specify both the data types of your variables (e.g. int, string, bool) and also the merge-types (e.g. "this merges as a bank account balance, or a LWW unique ID, or a collaborative text field"). This is all the application programmer needs to specify. The rest of the synchronization algorithm gets automated by middleware libraries that the programmer can just use and rely upon, like his compiler, and web browser. I'd encourage you to check out the Braid spec, and notice how much we can do with how little. This is because HTTP already has almost everything we need. Compare this with the WebDAV spec, for instance, which tries to define versioning on top of HTTP, and you'll see how monstrous the result becomes. Example here: https://news.ycombinator.com/item?id=40481003 https://news.ycombinator.com/item?id=40481003

skybrian 2y ago
Thanks. Yes, that's a much more fine-grained use of versioning than we use in git repositories. I suppose this sort of synchronization is more like a streaming protocol than a version-control system. (A stream of updates.)