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>