"everything is a file" and beyond

I was thinking this morning about general "everything is a file"
philosophy...

I believe it's the philosophy in Plan 9 (though I don't really know all that
much about it) that everything is a file.
(In VSTa at least, it's more that nothing is a file but servers may follow
conventions that enable you to think of them as filesystems.)

Anyway...

"Everything is a file"

Thinking of all resources as files in interesting. If one can
open/read/write/close a file, one has a good chance of being able to
open/read/write/close any resource. Being able to address everything in a
unified namespace is interesting, too. However, the general file IO commands
don't provide a general way to deal with attributes associated with a
resource.

A file has a pathname and data to read or write. It also has a
server-defined (and maintained) set of visible attributes including
timestamp, permissions, size, etc. Another resource would have different
attributes, for example, a serial port adds attributes for baud, parity,
flow-control, etc. The API for setting attributes is resource-specific,
unfortunately. From a shell script, for example, I could read and write from
a serial port resource the same way I would from a file, but I need special
support to set the baud rate (e.g., a setup command). It would be better to
have a consistent interface to all resources. From the script, I just need
to know the desired attribute names and values, e.g., attr_set("/dev/cua",
"baud", "57600").

An alternative to having a direct attribute interface would be to attempt to
express attributes as part of the path name, which can seem appealing, e.g.,
/ip/www.somewhere.com/80/tcp for a TCP stream with particular host and port
attributes (the server might use gethostbyname, create /ip/1.2.3.4 and make
/ip/www.somwhere.com a symbolic link to it). This becomes less appealing
when there are many attributes, though, e.g., /dev/cua/57600/8/N/1/hw/raw
(which gets even worse when we add read timeout and write timeout).

"Everything is a directory"

My next thought was why not adopt "everything is a directory" and use
(virtual) files for attributes. For example, a trivial GUI using a
hypothetical gui "filesystem" would have the following directories/files:
(written as path : contents of file)
/gui/myApp/mainWindow
/gui/myApp/mainWindow/type : window
/gui/myApp/mainWindow/x : 0
/gui/myApp/mainWindow/y : 0
/gui/myApp/mainWindow/width : 100
/gui/myApp/mainWindow/height : 100
/gui/myApp/mainWindow/textField
/gui/myApp/mainWindow/textField/text : "Hello, World!"
/gui/myApp/mainWindow/textField/x : 10
...
/gui/myApp/mainWindow/closeButton
...

A shell script could generate such an application using nothing but "mkdir
foo" and "echo 'n' > foo/bar"
(and provide a handler for user action (which would be read from an event
"file" (and symlinks could link child window events to parent for a single
application-level event "file")).

While this would seem like a lot of overhead (a file for every attribute),
these are only conceptually files and could be extremely low overhead.
Still, I guess that means we have conceptual overhead. :-) (And with the C
file API, it is nontrivial overhead to get/set an attribute (open,
read/write, close).)

Taking the "everything is a directory" idea to the extreme, consider a
"compound document" such as a document with embedded hyperlinks, tables,
figures, and pictures. It would be tempting to describe the document as a
directory, perhaps each paragraph as a directory, text, figures, links, etc.
as files. However, with a document, it's critical that the contained objects
be maintained in order. Filesystems do not generally maintain order of files
within a directory, which leads me to...

"Everything is XML"

XML elements have a name (tag), attributes, and content. They may nest (i.e.
additional elements may be contained in the content), and order is
preserved. It would be trivial (or at least very straightforward) to provide
an XML view of a filesystem. Obviously, XML would be appropriate for the
"compound document" example (consider xhtml). It would also work well for
the GUI example.

Some modern applications, incuding the OpenOffice.org suite, have adopted
XML document formats, but they maintain a clear distinction between XML
files and the filesystem where they're stored. With "everything is XML" the
distinction between filesystem and XML file need not exist. There needn't be
"open file" and "save file" or file manager systems. One just moves through
the XML world, "zooming" in on the desired portion (e.g., a virtual document
in the larger virtual file cabinet in the larger virtual office...).

All that's needed to accomplish this sort of abstraction is an agreed-upon
set of messages/handling that servers can implement, just as with the
filesystem "illusion." (To take this to the extreme of an "XML World" with
"zooming," we'd also want some kind of seamless application handoff at the
zoom points (to give the effect that a single viewer supports the entire
World), but I don't want to go there yet.)

"Everything is just a message client/server"

Taking a step in the other direction, one could just make sure the script
language has support for msg_connect, msg_send, etc., and that's all you
need. This is an equally valid though much lower-level view. ("Everything is
an atom" :-)

Opinions?
What sort of XML messages would be needed/desired? (In addition to the
messages used for virtual filesystems, we'd need to add general attribute
read/write and order-preserving container support (iterators,
order-preserving insert/delete))
Is VSTa the best platform for such an experiment?
Received on Wed, 25 Feb 2004 09:38:27 -0700