From owner-freebsd-hackers Tue Sep 4 17: 8:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guru.mired.org (okc-94-248-46.mmcable.com [24.94.248.46]) by hub.freebsd.org (Postfix) with SMTP id C83B437B406 for ; Tue, 4 Sep 2001 17:08:45 -0700 (PDT) Received: (qmail 39510 invoked by uid 100); 5 Sep 2001 00:08:44 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15253.27916.591039.936494@guru.mired.org> Date: Tue, 4 Sep 2001 19:08:44 -0500 To: Kevin Way Cc: Joseph Mallett , freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. In-Reply-To: <20010904214343.B77906@bean.overtone.org> References: <00000925020cf507d1@[192.168.1.4]> <20010904161534.A97071@NewGold.NET> <20010904214343.B77906@bean.overtone.org> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ 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 Kevin Way 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..... 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