[openbeos] Re: (Network) File Systems
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 06 Aug 2002 15:28:48 CEST (+0200)
Mat wrote:
> To begin with a file system has complete control on the namespace it
> represents
> and you can mount it at abritrary points in the file system. So "$>
> cat
> /http://www.openbeos.org > ~/www.openbeos.org.html" would access the
> (read
> only) http: file system which would then parse the domain name and
> then attempt
> a http get.
> While "$> cat /http://baron:password@localhost/etc/passwd > ~/
> security-risk"
> would cause the http: file system to attempt a login and then a get.
Nice :-)
That's exactly the idea I had in mind for this stuff (also for a zip
fs; e.g. /zip/boot/home/archive.zip would give access to /boot/home/
archive.zip as if it would be a directory).
> The clipboard file system is trickier. The clipboard is (currently)
> an
> application pull service that uses BMessages. Meaning the file system
> would
> have to have a BClipboard object and decoded BMessages, ick.
>
> Because these two examples bring up a single issue. If a file system
> is in the
> kernel an kernel space how do you add incredible features without
> burdening the
> kernel and risking it's stability?
The standard way would be to create a userland server that talks to the
file system which would do not much more than IPC in this case.
Of course, this has the disadvantage that you'd need to start the
server first before the file system can do anything useful.
Adios...
Axel.
Other related posts:
