[openbeos] Re: (Network) File Systems
- From: GThom@xxxxxxxxxxxxxxxxxx
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 6 Aug 2002 09:32:43 -0400
What about a simple driver / addon?
Gary Thom
WeightWatchers.com
888 Seventh Avenue, 8th Floor
New York, NY 10106
Tel : (212) 981 2880
-----Original Message-----
From: Axel Dörfler" [mailto:axeld@xxxxxxxxxxxxxxxx]
Sent: 06 August, 2002 11:29 AM
To: openbeos@xxxxxxxxxxxxx
Subject: [openbeos] Re: (Network) File Systems
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:
