[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    RE: KURL bugs: defending RFC 1738
From:       "Glen Parker" <glenebob () nwlink ! com>
Date:       1999-06-18 18:18:29
[Download RAW message or body]

> > UNC names are part of life. You cannot simply declare it to be Microsoft
> > bullshit.

No?  ;-)

> UNC's and URL's are two different things. KDE uses URLs.

I agree.  AFAIK, UNC's are used only for SMB and local access.  Kindof a
shortcut for 'smb://machine/dir/file'.  They aren't very useful in a mixed
environment.  Adding a helper to translate a UNC path into a 'smb://' url
would be kludgy, IMO.

> > Today, people freely embed references to the UNC names in email
> messages and

That's incorrect usage.  How do you expect say, an SGI box to use such a
beast?  The 'U' in UNC means 'universal', as long as you have a Windows box.
Kindof a strange interpretation of 'universal', I'd say.  UNC's are right
out IMO.

Of course, sending file:// URL's around is incorrect also, since it does not
provide a retrieval method.  Therefore it is only usefull on the local
machine, to specify a file accessible through an [f]open call.  IE,
file:///file must be interpreted as '/file' and passed to fopen().  The URL
file://host/file is useless.  How are you to access the file on the host?
It's anybody's guess.  Based on that reasoning, here's what I come up with:

file:path/file is incorrect WRT the RFC, but can only mean one thing:
path/filename, a relative path.
file:/path/file is incorrect WRT the RFC, but is also unambiguous: absolute
path /path/file.
file://file is incorrect, ambiguous, and useless (yes, all three).  The RFC
says that it specifies just a host.  Hosts are useless in a file: URL.
file://host/path/file is correct, but useless.  How do I talk to the host?
file:///path/file is correct and usefull : absolute path /path/file on the
local machine.

IMO, file: URL's can't have host names in them.  That's not what the RFC
says, but the RFC if wrong.  It can't work.  So, I suggest that file: URL's
always be interpreted as having no host.  That would mean then the URL
file://path/file is a relative path.  In short, an even number of leading
slashes (including none) is a relative local path, and an odd number of
leading slashes is an absolute local path.  More than three leading slashes
is an error.

I also don't buy the notion of translating a file: URL into and smb: or nfs:
URL.  If you want one of those access methods, specify it, otherwise assume
the [f]open() calls can handle it.

 --
Glen Parker               (not liking the file: url anymore ;-)
glenebob@nwlink.com

[prev in list] [next in list] [prev in thread] [next in thread]