Date: Tue, 04 Sep 2001 09:19:07 -0400 From: Michael Sinz <msinz@wgate.com> To: Paul Chvostek <paul@it.ca> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Should URL's be pervasive. Message-ID: <0000046c02083c07d1@[192.168.1.4]> References: <20010830111018.A97057@ussenterprise.ufp.org> <20010830111708.A20961@osaka.louisville.edu> <20010830232109.A1077@dylan.home> <00000e180511ee07d1@[192.168.1.4]> <000046d0064aa607d1@[192.168.1.4]>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Chvostek wrote:
>
> On Fri, Aug 31, 2001 at 02:15:09PM -0400, Michael Sinz wrote:
> >
> > I too have been hoping for (and building internal tools) that work
> > this way. I really wish you could just do:
> >
> > open("nfs://server.name.dom/directory/file.txt")
>
> NAME
> amd - automatically mount file systems
> ...
> DESCRIPTION
> Amd is a daemon that automatically mounts filesystems whenever a file or
> directory within that filesystem is accessed. Filesystems are automati-
> cally unmounted when they appear to be quiescent.
Ahh, but that assumes that your AMD configuration has all systems and mount
points enumerated in it. Let me see - I think that 30gig drive may be big
enough for that file :-)
> > and have it work. That would be nice. (Replace the above with
> > ftp: or http: or whatever other protocol would provide read and/or write
> > access.)
>
> What you're looking for is a substitute open() function. Perhaps
> someone should just write a URI base library. Put it in the public
> domain, of course, so that all UR base is belong to us....
Ahh, but that does not address all software. Sure, edit all source and
make the call to open() now be a call to uri_open()... Why bother making
the OS deal with the issues involved?
The reason the OS should (and could) is that it is the base from which
all such services grow. Now, in a microkernel design (such as the
previously mentioned HURD) there are ways to extend the filesystem to
include new types (FTPFS is a great example of such a filter/expansion)
but in FreeBSD (very much not microkernel) this then becomes an OS
issue or a user-program issue. If it is in user space you end up with
"some have it" and "some don't" and "some have some subset" which
makes it really nasty.
Can you imagine if there was an ide_open() to open files on IDE drives
and a scsi_open() to open files on SCSI drives? Or a UFS_open() vs an
ext2_open() vs an FFS_open()? Why would you then want a uri_open()
vs regular open()?
> <ahem>
Watch those puns - I could end up returning them unopened :-)
--
Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com
A master's secrets are only as good as
the master's ability to explain them to others.
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?0000046c02083c07d1>