Re: Random idea:
Greetings,
I like the magic approach. Though it is still a form of
guessing/estimation, I imagine the accuracy is fairly high. Programs
compiled with the magic library would be able to get the typing
information regardless of the underlying file system. Though most of
the time your system uses the native file system, it seems to me one of
the ideas behind hurd is to eliminate those constraints. In addition
to providing access to various file system (dos, usf, ext2, etc),
things that are not normally thought of as file systems can be treated
as such (ftp, http, etc.). Also it is probably not a good idea to
clutter up a file system with extra information that may or may not be
used. After all the main purpose of a file system should be the
efficient storage and recall of data whatever its content may be.
* Obligatory Random Idea:
Has anyone taken a look at Plan 9/Inferno. They have made some
interesting design decisions. One of the most interesting is to
elevate the concept of files. Not only are all physical devices files
(like Unix), but running programs can be treated as files. An example
given was a name server. To get the information a process would write
the request to the name server file. Reading that same file after the
request would provide the address information. Apperently the idea
was to limit the type of operations that processes had to provide to
basic file reads and writes.
To make a shell metaphor:
$echo gnu.hurd.org > /system/nameserver
$cat /system/nameserver
Name: www.gnu.org
Address: 198.186.203.18
Aliases: hurd.gnu.org
>>>>> "Gregory" == Gregory Ade <gkade@bigbrother.net> writes:
Gregory> To me, it seems a hard call where to put code that would
Gregory> manage this; if you use a filesystem where everything is
Gregory> an object (and not just a stream), then you turn it into
Gregory> a filesystem thing. if you use a "normal" filesystem
Gregory> (like ext2), then you'd have to add a layer on top of it,
Gregory> a-la OS/2 and FAT16 with it's "wp data. sf" and "ea
Gregory> data. sf" files... But then, in either case, you'd need
Gregory> a component in the GUI to interface to either of the
Gregory> filesystems...
--
Thanks,
George
dowdingg@math.uaa.alaska.edu
http://www.math.uaa.alaska.edu/~dowdingg
Reply to: