From owner-freebsd-hackers Wed Sep 5 2:22:21 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 0D72237B406 for ; Wed, 5 Sep 2001 02:22:14 -0700 (PDT) Received: (qmail 56303 invoked by uid 100); 5 Sep 2001 09:22:13 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15253.61124.936424.530720@guru.mired.org> Date: Wed, 5 Sep 2001 04:22:12 -0500 To: Kevin Way Cc: Mike Meyer , jmallett@newgold.net, freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. In-Reply-To: <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> <20010905014148.A90520@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: > > 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. Old idea. I first saw an ftp version of this in '91 or '92. Last time I went looking for source code, I couldn't find it, so I have no idea who to credit. > > 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. Hopefuly, an http file system will have options to let you specify a username and password, so you can mount password-protected "volumes" that way. Or possibly a place to specify an authentication realm file, giving username/password pairs for the various different realms that might be in the mounted tree. > 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. I can't argue that having that capability on a workstation would be nice. I don't think it's something I'd make a lot of use of, and I'm not really interested in adding it. > 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 think it's more a case of topic drift. This thread started with the observation that URLs were ubiquitous, and asked whether or not they should be pervasive as well. Your - and presumably Mike's - proposed solution doesn't deal with that at all. > > 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. I agree about that. On the other hand, there are commands that take arguments with information that can be put into a url. Because URLs are ubiquitous, it would be nice if those commands would extrat that information for you. I.e. - ncftp grew the ability to deal with FTP urls. fetch carries that even further. I can see wanting a mail composition program that would recognize a mailto URL on the argument line, and pull out the address and subject for you. One of the suggestions that fell out of this was that there be a shell command for doing these kinds of things. While I like that idea, I think the shell command should be a wrapper around some library calls, so that this kind of thing can easily be added to commands where appropriate. Especially since we already have half the functionality - if in a crippled form - in libfetch. This is something I'm willing to work on, and have even started on. I submitted PR 30318, which adds the missing half the functionality to libfetch - but doesn't do any healing of the first half - and a small program that tries to act like the "url" command described earlier on the thread. > I apologize for the miscommunication. I don't think one is necessary, or if one is, I need to apologize as well for missing the change in direction. 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