[openbeos] Filesystems, Namespaces and Data

  • From: Mathew Hounsell <mat.geek@xxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Wed, 7 Nov 2001 03:28:32 -0800 (PST)

Data, Data, Where fore art thou Data.
        (Sounds like a bad 'ST:TNG' quote.)

I have been planning to write an article for the list on my idea, so here

In the original concept the designers had for the BeFS, they foresaw a
relational database. This would allow the user to manipulate all their data
as entries in a database. This is a twist of the concepts from the already
existing file systems.

A file system is only a means of mapping an identifier (usually a absolute
file name) to data (the files contents) and its attributes (such as
permission, ownership, creation time etc).

File systems are usually accessed through a name space. Most of these
namespaces are hierarchical in structure, creating a hierarchical absolute
path for a file. This absolute path is internally mapped to the files
attributes and contents. The term namespace is used to mean a system for
containing names. Namespaces are used to map a name to data. Since a name is
itself data, the most generally form of this concept can be called a
dataspace. A dataspace is simply a means of mapping data to data. 

File systems are also used to access the hardware and store the data
contained in the file system's dataspace. This side of the file system can
be conceptually separated from the mapping concepts.

Be added user defined attributes to files to give developers and users the
ability to store information about data without requiring the data to be
read. Attribute support was then added to the system shells. Files with no
data started to appear all their data was stored in the attributes. Soon
directories were created that contained only empty files of the same mime
type. These directories represented a pseudo-database implemented upon the
file system.

Since a dataspace only maps data to data, it's conceptually possible to
mount a dataspace within another dataspace. Accesses to the internals of
this subspace are directed through its handler. All access to the external
dataspace continues to be directed to its handler.

With the write file system drivers it would be possible to mount any
dataspace within the current BeOS file system. The idea of mounting an
archive file has already been raised by developers. This is an example of
mounting data within a dataspace as an individual dataspace. It is
technically possible to mount an external site accessed through FTP, as has
been suggested.

I am proposing we abstract away the file system, the Internet, the user's
system model and smaller things, like users' preferences. After all these
are only limited abstractions themselves. I propose we start at the kernel
layer and create the facilities for loading a dataspace. In libraries we
provide all the common code for maintaining a dataspace. Upon these services
we implement the file system's namespace and things like user preferences.

This would then remove all the complication of creating a full file system
driver from developers. Those who wished to map data like a zip file, an FTP
site or a CD database would only have to write the data handlers. This would
also allow an application to access a dataspace uniformly no matter what it
is. If the user has a database containing all 3000 medical images for a
doctorate and they wish to manipulate them, they can open the database as a
'directory' within tracker and read and change the fields in each field
(attribute). They can also open their database with their favorite image
viewer and run a slideshow. They can also run complex queries using
tracker's query feature.

I am not proposing a change to the application level API. Only additions to
the OS level API. Since we are writing them from scratch, the operating
system and drivers can be written to work within the new framework without
changing the behavior of any application, server or legacy driver. The many
point of change would be stubs of the VFS API mapping to the new dataspace

I know the first response, "Not in R1, BeOS R5 only". It is a good decision,
but I believe that in the medium to long terms this will save time. But most
importantly it will take OpenBeOS beyond Windows, Solaris, Linux etc, and
into a position they have long to be. Look inside Window's registry,
especially at the contents of My Computer,
 Sun developed the Network Information Server for Solaris. Linux will get
there eventually.

Sincerely, Mathew Hounsell.

P.S. I do have ideas for implementation, but I thought they could wait.

P.P.S I became more ceratin of this idea as I looked at working on Open
Tracker or deploying Component Technologies and the need to write the Mime
Type code for OpenBeos not to mention the Translator Kit. 

 Get 100% private, FREE email for life from Excite Australia
 Visit http://inbox.excite.com.au/ 

Other related posts: