Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Sep 2001 01:41:48 +0000
From:      Kevin Way <>
To:        Mike Meyer <>
Subject:   Re: Should URL's be pervasive.
Message-ID:  <>
In-Reply-To: <>; from on Tue, Sep 04, 2001 at 07:08:44PM -0500
References:  <00000925020cf507d1@[]> <> <20010904161534.A97071@NewGold.NET> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 04, 2001 at 07:08:44PM -0500, Mike Meyer wrote:
> Kevin Way <> types:
> > I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://local=
> > should do something useful.  Nor do I consider his idea "lazy".  I do t=
> > that he was suggesting, and I concur, that there's no logical reason th=
> > networked file access should be treated differently by user applications
> > than local file access.
> I would concur with that, so long as you remember that "local file
> access" involves someone making usually-privileged system calls to
> arrange to map those remote name spaces into the local name
> space. That is different from making URLs pervasive.

Agreed.  You'll notice I agreed with Michael Sinz's post, not the
pro-URL posts.  I like the idea of being able to say...

mount -t http /www/freebsd
cat /www/freebsd/doc/en_US.ISO8859-1/books/faq/index.html

even a simple example like 'cat' seems nice, but it
raises as more questions than it answers.

Obviously protocols which are not file oriented won't translate effectively
into filesystems.  mailto is an excellent example of a scheme that doesn't
translate effectively into a filesystem translation layer.  I'd have no idea
what to do with a mailto url, or how to reference it as a filesystem.

Combine the above filesystem concept with something like amd, and many
activities become extremely convenient.

> > I strongly suggest you read his post again, and think about how nice it=
> > for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, S=
> > etc and have user-level programs access their data in exactly the same=
> > manner.
> Those are all file systems, and operations on the things on them all
> have pretty much the same semantics. This isn't true for URLs in
> general.


> It's true for some subset of the available schemes, and don't think anyone
> would object to file system modules for ftp or http.=20

this is what the post I agred with was suggesting.  this is what i believe
would be a good idea.

> You can even do this in userland with an nfs server API if you
> want it to be portable.

Novel idea.  I'll file it into the maybe pile.

> I don't know of any application that handles local files that responds
> to any open error by prompting for a password. If "open" can now
> return an HTTP 401 error, every application is going to need to be
> able to deal with that in some sane way. Either that, or users are
> going to have to know the proper syntax for usernames and passwords in
> every URL scheme they deal with - and start putting passwords on
> command lines, and other things that give security officers
> nightmares.

I would imagine that an http filesystem layer would return EACCES for a
401, as that would probably cause any program to return a sane error to
the user.

> > This is not an LSD-induced 'turn freebsd into windows' idea, it's a very
> > simple extension of ideas that FreeBSD already has in place.
> Conceptually, it may be very simple. In practice, it's very, very
> messy. The correct thing to do with a URL is going to depend on the
> application that's doing it, what the application is doing, and the
> scheme for the URL. The application is really the only thing that can
> figure all that out. In the simplest possible example, "cat" can just
> treat appropriate URLs like files and read from them. "vi" - or
> something that vi is talking to - needs to be taught how to deal with
> streaming data in some way.

Yes, unfortunately all ideas are just a Simple Matter of Programming...
One miscommunication I should apologize for, I'm not suggesting the
URLification of FreeBSD.  I'm suggesting that it would be a Good Thing if
files available via any common networked file transfer protocol were able
to be accessed via standard system calls.

> In summary, each command needs to decide - possibly on a case-by-case
> basis whether or not the string it's got is a URL or a file name. It
> needs to decide how the operation it's been asked to be performed can
> be performed on the object that URL represents, and if so how it
> should be mapped. If it's a URL, the application may well have to deal
> with events that don't happen with local files.

I really don't want all that in every command.  I want it in a filesystem
layer, where appropriate, as described above.

Anyway, in conclusion it would seem to me that we agree, but there was a
misunderstanding because I did a poor job of clipping relevant text to
show what it was I was agreeing with.

I apologize for the miscommunication.

Kevin Way

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see



To Unsubscribe: send mail to
with "unsubscribe freebsd-hackers" in the body of the message

Want to link to this message? Use this URL: <>