On Sun, 2003-02-09 at 11:30, will wrote:
> Hi folks,
> a weird and wacky idea for everyone:
> wouldn't it be cool if you could
> 'fopen("ftp://10.10.10.9/mystuff/me.plan","rw")' and
> it worked? Why does each protocol need to be handled
> by special libraries, when to the application layer it
> is purely a file stream?
> I propose that Syllable implement a multiple-root
> filesystem. The local filesystem remains in the
> "file://" root, but additional roots can be added by
> kernel modules e.g. the "http://" root and the
> "ftp://" root. Each exposes conventional structure,
> with the feature that if you open or manipulate a path
> that does not exist in the virtual representation of
> that system, it might be added (e.g. you can open
> "http://syllable.sourceforge.net/" and it will be
> automagically added to the http:// root if you did not
> already have it 'mounted').
> This would allow any url to be passed as a filename
> argument anywhere, and it is up to the platform to
> understand these urls instead of each individual
> application. Within a filesystem normal directory
> navigation is possible.
> The nature of remote filesystems means that additional
> methods might be useful in the FILE objects, e.g.
> 'metric()' returns a rough access cost so that
> applications can have sensible strategies for dealing
> with different speeds of resource if the application
> programmer cares to invest the time (although it will
> work just fine without anyway).
> This doesn't mean that there isn't room of dedicated
> protocol libraries and dedicated applications, as this
> FS approach will only expose the
> lowest-common-denominator of functionality; but this
> approach makes 99% of general applications more
> A central multi-root filesystem as I outlined can also
> lead to efficiencies in the central caching of data,
> for example.
> A good example of this done in userland: google for
> libferris or look at
> A counter-link to bare in mind:
> I eventually intend to put forward the idea that other
> things (not just filestreams) can be accessed using
> urls and a plugin architecture in the platform (not
> via third-party-libraries); e.g. mail, instant
> messaging, etc.
> To complicate the replies to this message further, I
> have some other ideas to shout about:
> is any of this interesting?
This is definitely interesting, and not really new. There are several
ftp/http filesystems available for Linux, and I understand Plan9 does
things like you want. The only difference I can see is that your
ftp/http system is not rooted in the filesystem heirarchy. This may or
may not be a problem (or an improvement), and should be fleshed out.
The advantage of putting them into the filesystem heirarchy is that we
don't need to change syllable at all. Just write an http filesystem,
and an ftp filesyste, and whatever filesystems you want, mount them in
/http and /ftp and whatever else, and go. Then, you would have almost
what you want, with no changes. A small change could be made to libc to
translate filenames of the form "http://..." to "/http/...", and we
would in effect have what you want. This has the main problem we need
to modify libc for each new type of filesyste (to do the translation).
One thing to note: while ftp works great via filesystem like access (it
is, afterall, a form of networked filesyste), http does not. This is
because of the "multiple file" nature of an http document. When you go
to a web site, you are not seeing one file, you are seeing many,
frequently many. What should the http filesystem get, and where should
it put it? It can be done, as wget can get a mirror of a page, it's
just not easy. Also keep in mind that except for download links, the
overwhelming majority of apps would not benifit from being able to
access the http:// namespace because they won't understand html.
All this said, it's generally a good idea, and should be done for at
least ftp as a proof of concept. (Ftp is the easy case). Incidentally,
you don't need kernel modules to do this what you want to do, only what
I propose. Plugins/modifications to libc/appserver would be quite
capable of doing what you propose. It's only when you get to actual
filesystems that you need kernel modules.
Daniel Gryniewicz <dang@...>