Date: Wed, 5 Sep 2001 04:22:12 -0500 From: Mike Meyer <mwm@mired.org> To: Kevin Way <kevin.way@overtone.org> Cc: Mike Meyer <mwm@mired.org>, jmallett@newgold.net, freebsd-hackers@freebsd.org Subject: Re: Should URL's be pervasive. Message-ID: <15253.61124.936424.530720@guru.mired.org> In-Reply-To: <20010905014148.A90520@bean.overtone.org> 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> <20010905014148.A90520@bean.overtone.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Way <kevin.way@overtone.org> 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. <mike -- Mike Meyer <mwm@mired.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15253.61124.936424.530720>