From owner-freebsd-hackers Tue Sep 4 18:42:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from femail40.sdc1.sfba.home.com (femail40.sdc1.sfba.home.com [24.254.60.34]) by hub.freebsd.org (Postfix) with ESMTP id EB0CE37B40C for ; Tue, 4 Sep 2001 18:42:06 -0700 (PDT) Received: from bean.overtone.org ([24.249.254.100]) by femail40.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010905014206.ILRD4874.femail40.sdc1.sfba.home.com@bean.overtone.org>; Tue, 4 Sep 2001 18:42:06 -0700 Received: by bean.overtone.org (Postfix, from userid 1001) id 529F05B4DB; Wed, 5 Sep 2001 01:41:48 +0000 (GMT) Date: Wed, 5 Sep 2001 01:41:48 +0000 From: Kevin Way To: Mike Meyer Cc: jmallett@newgold.net, freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. Message-ID: <20010905014148.A90520@bean.overtone.org> References: <00000925020cf507d1@[192.168.1.4]> <20010904161534.A97071@NewGold.NET> <20010904214343.B77906@bean.overtone.org> <15253.27916.591039.936494@guru.mired.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15253.27916.591039.936494@guru.mired.org>; from mwm@mired.org on Tue, Sep 04, 2001 at 07:08:44PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --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 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