- From: Michael Toomim <toomim@gmail.com>
- Date: Wed, 5 Feb 2025 01:27:57 -0800
- To: ietf-http-wg@w3.org
Julian, I still don't think you're understanding the difference between Option 1 and Option 2. Commenting on Option 2 is not going to anywhere until we understand the difference between the two Options. Cheers, Michael On 2/5/25 1:01 AM, Julian Reschke wrote: > (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:28:04 UTC