- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 5 Feb 2025 10:01:34 +0100
- To: ietf-http-wg@w3.org
(only commenting on excerpts related to Option 2) On 05.02.2025 01:53, Michael Toomim wrote: > ... > == *Option 2: a Many-to-Many Mapping:* == > > Rather than defining Versions /as/ Resources, in Option 2 we see them as > a /dimension of/ Resources. A version *is* a resource. You are conflating multiple concepts: - is a version a resource? - can a URI be assigned to any resource? - does that URI need to be an HTTP URI? The answers are: yes (see <https://www.rfc-editor.org/rfc/rfc3986.html#section-1.1>, item "Resource), yes, no. > ... > We can address the Version (time) and Range (space) of a Resource > independently, with headers: > > GEThttps://example.com/hello.txt > Range: lines=44-100 > Version: 1.4.5 > ... ...which defeats cacheability. > ... > HTTP does not require Ranges to be URIs, and nor should we (in this > model) require Versions to be URIs. Applications can rather *choose* to > define a URI schema for versioned ranges themselves, if desired, such as: > > https://example.com/hello.txt?lines=44-100&version=1.4.5 > ... Yes. The question is whether it's a good idea to define an HTTP URI for each version (I believe so). > ... > If such URI schemes are popular enough, they can be standardized. But > this can be done in a separate specification. When a Version is an > independent *dimension of* a Resource, there is no useful way to give a > Version itself a URI. > ... How so? > ... > == *Use-Cases: simple Distributed Systems that need Option 2* == > > Here are two use-cases that cannot be supported in Option 1, because > they describe multiple resources (potentially on multiple computers) as > read and/or written at the same "time": > > Example 1: Suppose we want to expose a Git repository over HTTP. In Git, > multiple files are committed together at the same version: > > https://company.com/git_repo/README.md > https://company.com/git_repo/package.json > https://company.com/git_repo/main.js > > All three of these files are at the same version: "83b6f9c". > ... No, that's an identifier of a commit (an atomic change of multiple resources). And yes, it can have an HTTP URI, and indeed has on Github. Examples: HTML: <https://github.com/httpwg/http-extensions/commit/f7d04fee15a7ffd8d5bdaf84277d38548c5ea8a1> Raw commit data: <https://github.com/httpwg/http-extensions/commit/f7d04fee15a7ffd8d5bdaf84277d38548c5ea8a1.patch> Note that a commit can have URIs on multiple servers (for instance, Github vs Gitbox). They could point to each other with a Link header field, but do not have to. One server can also redirect to another server: ~~~ > curl -v https://gitbox.apache.org/repos/asf?p=jackrabbit-oak.git;a=commit;h=19bcc44cdc355050e57fd75a350923a6db0d3bc6 * Host gitbox.apache.org:443 was resolved. * IPv6: 2a01:4f9:3080:3e9e::2 * IPv4: 135.181.246.12 * Trying [2a01:4f9:3080:3e9e::2]:443... * Trying 135.181.246.12:443... * schannel: disabled automatic use of client certificate * ALPN: curl offers http/1.1 * ALPN: server accepted http/1.1 * Connected to gitbox.apache.org (135.181.246.12) port 443 * using HTTP/1.x > GET /repos/asf?p=jackrabbit-oak.git HTTP/1.1 > Host: gitbox.apache.org > User-Agent: curl/8.10.1 > Accept: */* > * Request completely sent off * schannel: remote party requests renegotiation * schannel: renegotiating SSL/TLS connection * schannel: SSL/TLS connection renegotiated * schannel: remote party requests renegotiation * schannel: renegotiating SSL/TLS connection * schannel: SSL/TLS connection renegotiated < HTTP/1.1 302 Found < Date: Wed, 05 Feb 2025 08:58:38 GMT < Server: Apache < Location: https://github.com/apache/jackrabbit-oak < Content-Length: 224 < Content-Type: text/html; charset=iso-8859-1 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://github.com/apache/jackrabbit-oak">here</a>.</p> </body></html> * Connection #0 to host gitbox.apache.org left intact ~~~ > There is no way to represent this multi-resource Version in Option 1, > because each Resource is presumed to have its own namespace of time. No. A commit (which represents *changes* to a set of resources) is a resource itself, and of course can have an HTTP URI. > Consider: if you tried to construct a unique URI to represent this > Version 83b6f9c, what would the URI be? You could call it "https:// > example.com/version/83b6f9c", but what would be the result of doing a > GET on that? There's no sensible response body for a Version alone, > because a Version is not itself a Resource. > ... See above. A version *is* a resource, and so is a commit. > Example 2: Consider a distributed bank account transaction, between > Alice's account on https://alice.com and Bob's account on https:// > bob.com. Alice and Bob both start with $20, and then we transfer $10 > from Alice to Bob, by debiting /Alice and crediting /Bob at the *same > time:* > > PATCHhttps://alice.com/alice > Version: "transaction-1" > Content-Type: application/debitcredit > > -10 > > PATCHhttps://bob.com/bob > Version: "transaction-1" > Content-Type: application/debitcredit > > +10 > > To mark these mutations as occurring at the same time, we gave them the > same Version "transaction-1". If this Version was itself to be a URI, > ... I think you are conflating a *version* with a *change* of multiple versions (aka a "commit" in Git). > ... Best regards, Julian
Received on Wednesday, 5 February 2025 09:01:40 UTC