Re: File URIs, home and relative paths

On 12 June 2016 at 12:47, Jason Dusek <jason.dusek@gmail.com> wrote:

> On Sat, 11 Jun 2016 at 18:26 Matthew Kerwin matthew@kerwin.net.au
> <http://mailto:matthew@kerwin.net.au> wrote:
>
> On 12/06/2016 10:40 AM, "Jason Dusek" <jason.dusek@gmail.com> wrote:
>> >
>> > On Sat, 11 Jun 2016 at 16:23 Matthew Kerwin matthew@kerwin.net.au
>> wrote:
>> >>
>> >>
>> >> On 12/06/2016 5:57 AM, "Jason Dusek" <jason.dusek@gmail.com> wrote:
>> >> >
>> >> > It is strange to me that the draft neither provides for home and the
>> present directory semantics, nor clearly speaks to the issue (in a section
>> titled "Special Paths in UNIX and File URLs" or something similar). Perhaps
>> it would inspire future work in this area.
>> >> >
>> >> > Kind Regards,
>> >> >   Jason Dusek
>> >>
>> >> In URI space current directory references are achieved using relative
>> references. "./foo/bar" is a valid relative reference, which can be
>> resolved against a base URI that represents $PWD.
>> >
>> > This works out strangely in practice because you can’t write
>> file://<something> to get it.
>> >
>>
>> Like I said at the very start, I think you're trying to use URLs for
>> something URLs aren't meant for.
>>
> That is by no means clear. Their charter is pretty broad. I would hope
> that ...://... could name everything under the sun.
>
​It can. Absolutely.  E.g.: "file://
115.64.214.208/home/matty/Projects/foo/bar" That doesn't mean it has to be
able to name everything **simultaneously**.
​

> Relative resolution is strictly hierarchical, always, in all hierarchical
>> URI schemes.
>>
>> URI templates can be used to achieve your non-hierarchical resolution,
>> using variable substitution.
>>
> Could ~ be made part of the RFC? It is an ubiquitous concept. Only at the
> beginning of a path, sure. What are the objections to that?
>
​It could, but the objection is: nobody does it.

The goal isn't to tell people what to do, it's to explain to other people
what is already being done. If we were to mandate that "
/~/*
" in a path has to be treated a special way, there'd be pushback from every
current vendor. Also: just by writing an RFC, we can't force existing
software to update itself; so it wouldn't interoperate with existing
deployments.
​


> >> User home directory and tilde expansion both, AFAIK, come from the
>> shell, not the file system. I could add a warning that a relative reference
>> that starts with "~/" (or "~username/") won't resolve against a base URI
>> the same way bash would resolve an equivalent path; but since no other URI
>> scheme special handles '~' is anyone going to find this valuable?
>> >
>> > Well, I have not been collecting statistics over the years — but many a
>> time have I seen confusion and consternation with file URLs. It seems
>> valuable to mention a feature that might be mistakenly expected but is not
>> provided for.
>>
>> I've never seen or heard of anyone confused by this issue. Do you think a
>> short warning to that effect would resolve your concern? Or, do you have
>> any text to propose?
>>
>> > It is worth pointing out that there are variety of “pseudo URL schemes”
>> that have grown up around Git which implicitly rely on resolution relative
>> to . or ~ on a remote server.
>> >
>> > Perhaps people will put some thought into an approach as a result.
>>
>> Sure, but you're talking about pseudo URL schemes, not misunderstandings
>> of the file: scheme. This is a whole new scope. Why don't you write a new
>> informational draft that addresses it?
>>
> I am happy to write such a draft; but I bring them up here just to point
> out they face the same issue with respect to home and dot and an accurate
> treatment of them puts them in disharmony with file://.
>
​Of course there'll be disharmony. They've been created because the
existing schemes can't do what people want. That's why new things get
created. It's not a problem.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/