Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Sep 2001 01:41:48 +0000
From:      Kevin Way <kevin.way@overtone.org>
To:        Mike Meyer <mwm@mired.org>
Cc:        jmallett@newgold.net, freebsd-hackers@freebsd.org
Subject:   Re: Should URL's be pervasive.
Message-ID:  <20010905014148.A90520@bean.overtone.org>
In-Reply-To: <15253.27916.591039.936494@guru.mired.org>; from mwm@mired.org on Tue, Sep 04, 2001 at 07:08:44PM -0500
References:  <00000925020cf507d1@[192.168.1.4]> <E15eICB-0007ny-00@twwells.com> <20010904161534.A97071@NewGold.NET> <20010904214343.B77906@bean.overtone.org> <15253.27916.591039.936494@guru.mired.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--6TrnltStXW4iwmi0
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 <kevin.way@overtone.org> types:
> > I'm quite sure that Mr. Sinz wasn't suggesting that telnet smtp://local=
host
> > should do something useful.  Nor do I consider his idea "lazy".  I do t=
hink
> > that he was suggesting, and I concur, that there's no logical reason th=
at
> > networked file access should be treated differently by user applications
> > than local file access.
>=20
> 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 http://www.freebsd.org/ /www/freebsd
cat /www/freebsd/doc/en_US.ISO8859-1/books/faq/index.html

even a simple example like 'cat http://www.freebsd.org/' 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=
 is
> > for a moment that you can mount CODA, 9660, NFS, FFS, UFS, FAT, NTFS, S=
MBFS,
> > etc and have user-level programs access their data in exactly the same=
=20
> > manner.
>=20
> 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.

Agreed.

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE7lYLcKxA01iDoLN4RAuOxAJ9+wpgwEehffmerYbTvLiAQFW6cJgCeNPhb
8CJU/ChnSb1v4keIyI9vMGY=
=dBhp
-----END PGP SIGNATURE-----

--6TrnltStXW4iwmi0--

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?20010905014148.A90520>