On 3/15/21 9:02 PM, Jonathan Nieder wrote:
> Drew DeVault wrote:
>> On Mon Mar 15, 2021 at 6:01 PM EDT, brian m. carlson wrote:
> 
>>> So I don't think this is a thing we can do, simply because in general
>>> URLs aren't suitable for sharing this kind of information.
>>
>> That's simply not true. They are quite capable at this task, and are
>> fulfilling this duty for a wide varitety of applications today.
>>
>> I don't really understand the disconnect here. No, URLs are not magic,
>> but they are perfectly sufficient for this use-case.
> 
> I'm not sure it's a disconnect; instead, it just looks like we
> disagree.  That said, with more details about the use case it might be
> possible to sway me in another direction.
> 
> To maintain the URI analogy: the URI does not tell me the content-type
> of what I can access from there.  Until I know that content-type, I
> may not know what the best tool is to access it.

This is a pretty odd argument. Drew is recommending that the URI
"git+https://" tells a person the right tool to obtain the resource ("do
I use curl/wget, or git clone"), and now you're arguing that that it is
somehow insufficient because "git+https://" doesn't tell the person
which media viewer application is best suited to display the contents
after it's been downloaded and no longer has an associated URI at all
(but does exchange that particular variety of metadata for a mimetype).

Why does this even matter? Again, the point here is the assertion by
Drew that, for the purpose of listing a manifest of remotely fetchable
resources, he sees a benefit to having some standard format for the URI
itself, describing how it's intended to be fetched.

- ftp:// -> use the `ftp` tool
- scp:// -> use the `scp` tool
- http:// -> use the `wget` tool
- git+http:// -> use the `git` tool

But instead of needing every program with a git integration to
reimplement "recognize git+http and do substring prefix removal before
passing to git", the suggestion is for git to do this.

There is definitely a (strange) disconnect here.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User