Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Sep 2001 19:08:44 -0500
From:      Mike Meyer <mwm@mired.org>
To:        Kevin Way <kevin.way@overtone.org>
Cc:        Joseph Mallett <jmallett@NewGold.NET>, freebsd-hackers@freebsd.org
Subject:   Re: Should URL's be pervasive.
Message-ID:  <15253.27916.591039.936494@guru.mired.org>
In-Reply-To: <20010904214343.B77906@bean.overtone.org>
References:  <00000925020cf507d1@[192.168.1.4]> <E15eICB-0007ny-00@twwells.com> <20010904161534.A97071@NewGold.NET> <20010904214343.B77906@bean.overtone.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Way <kevin.way@overtone.org> types:
> > If you're really lazy and want to be able to do:
> > 	telnet smtp://localhost
> > I suggest you look into this relatively new invention called 
> > '/etc/services' and read some manual pages. You'll find you can do 
> > something quite similar, and much saner.
> I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://localhost
> should do something useful.  Nor do I consider his idea "lazy".  I do think
> that he was suggesting, and I concur, that there's no logical reason that
> 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. For one thing, it
doesn't muck with the local name space. If URL's are pervasive and I
issue the comand "vi mailto:kevin.way@overtone.org", am I going to
edit a file in the local directory called
mailto:kevin.way@overtone.org, or am I going to send a mail message to
kevin.way@overtone.org? For another, it provides a place to hang
information that's global about that mapping - for instance, providing
uids and permission bits to handed back from file systems that don't
have them.

> I strongly suggest you read his post again, and think about how nice it is
> for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, SMBFS,
> 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 I
don't think anyone would object to file system modules for ftp or
http. You can even do this in userland with an nfs server API if you
want it to be portable.

However, not all URI schemes have that property. For instance, Mike
refers to emacs having "transparent FTP support". It's not really
transparent, as opening a local file never asks me for a password! If
the ftp server is mounted, then you can provide authentication
information as options to the mount. You can even deal with FTP
servers that want an ACCT command, which doesn't have a place in the
RFC 1738 ftp scheme.

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.

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

Sockets are similar in many respects. In a lot of ways, sockets look
like file descriptors with some extra functions that can be applied to
them. In many cases, all you do with a socket once you've got it is
standard file descriptor calls. However, the kernel doesn't let you
just "open" a socket. Yes, there are file systems that let you treat a
subset of the possible sockets and socket operations that way. But to
take full advantage of them, you have to use a different API.

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.

All of which is why I think we're already moving in the right
direction. We've got a library routine that you can hand a URL to, and
it hands back FILE *. We've also got routines that will parse the URL
so you can manipulate it, for instance plugging in a new password and
user name that the application got from the user in a manner
appropriate for that application.

For some reason, this all brings to mind the request to make open act
like the Perl open.....

	<mike
--
Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15253.27916.591039.936494>