file:/ vs file://<host>/ vs file:///

Daniel Veillard veillard at redhat.com
Thu Nov 4 23:54:46 EET 2004


On Thu, Nov 04, 2004 at 10:45:18PM +0100, Kenneth Wimer wrote:
> * Daniel Veillard <veillard at redhat.com> [Nov 04. 2004 22:23]:
> >   no. file:///foo is file://localhost/foo which means the local file /foo
> > similary after canonicalization file:////blah/blub is 
> > file://localhost/blah/blub i.e. /blah/blub on local host.
> > There is no syntactic definition yet for paths relative to the current
> > directory. This makes pushing any semantic for file:/foo in other specs
> > especially dangerous.
> 
> Cool. Makes sense to me. Thanks for the explanation.
> 
> Why don't we have a relative path definition (outside of the fact that
> it is not defined in RFCXXXX)? Wouldn't it be usefull and someowhat easy
> to implement (somewhat like KDE's file:/foo) in addition to the rest? It
> seems logical to me. Why does it make it dangerous as you say...I don't
> quite get that.

  There have been existing attempts to provide this in the file URI
framework but they were not standardized and IIRC conflicted (different
syntaxes). I would expect that one day someone will take to the challenge
to do a proper RFC for the file protocol definition (from an Internet
perspective those RFC are way outdated, most of the other parts of the
originals URL specs from Time Berners-Lee have been deprecated by new
RFC but nobody stood to the challenge to clean up the file: mess so far).
But the day this happens, there will be a lot of conflicts and it will
be a mess, because lots of different incompatibles extensions to the base
file protocol syntax have been deployed in various pieces of software.
The only way to play safe is to stick at least in our specs with what we
know is already cast in stone in the old RFCs.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



More information about the xdg mailing list