Re: File URIs, home and relative paths

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.

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?

>> 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://.

Cheers,
> Matty
>
Kind Regards,

Jason Dusek
​