Re: File URIs, home and relative paths

On 08/06/2016 2:50 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
>
> On 2016-06-08 01:39, Jason Dusek wrote:
>>
>> Dear List,
>>
>> The use of HTTP and other recognized URL schemes for resource
>> identification often overlaps with the use of files. For example, in the
>> specification of Python dependencies.
>> ...
>
>
> Time to review <
https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-10>, I guess :-)
>
> Best regards, Julian
>

​​
​I'm definitely taking Jason's comments on board, but I can't see anyone
implementing this.  In the case of the draft, my goal is updating the
scheme to fit with RFC 3986 and documenting the funny things people already
do, not inventing new things.

​Here are my thoughts on the proposal:

1. '.' already means something in URIs; you can't redefine it, even for
just one scheme, without rewriting RFC 3986 (possibly requiring a time
machine.)  Since '.' is an unreserved character we can't even use "%2E" to
smuggle it through the remove_dot_segments algorithm.

2. Presumably the proposed '~' and '.' are only special when they're the
first path segment*.  How would that interact with relative resolution?  To
me, as someone familiar with tilde expansion in bash, I'd expect
"~/foo/bar" to be an obvious relative reference, but if it were resolved
against a base URL with subdirectories in the path, the tilde would find
itself above the root, and thus lose all its special meaning.  We'd have to
use "/~/foo/bar" as the relative reference, which is unintuitive and kind
of counter to the proposal.

 * otherwise what would "/foo/~/bar" mean?

3. This would break: `mkdir -p /\~/foo ; touch /\~/foo/bar`
 ("file:///~/foo/bar" would always resolve to my home directory;
"file:///%7E/foo/bar" would too, since '~' is unreserved)

Off-list I suggested Jason use RFC 6570 URI templates, and define variables
like {+PWD} or {+HOME} in the context of his application (even though
"moustache templates" aren't aesthetically pleasing).  I still think that's
probably the best way forward.

Cheers,
Matty