Re: Database storage approach

[Duncan Pierce <cmrdrp soc staffs ac uk>]

Hi Tim,

On Tue, 27 Apr 1999, Timothy H. Keitt wrote:
> This is way off the original topic.  Nobody is talking about changing the user
> interface.  They are talking about changing the programming interface.  When
> you are typing away in bash, you don't need to know whether you are accessing
> a database or a standard file system.  The problem with most file systems is
> that they are like unencapsulated data---they allow you to do stupid things.
> And like it or not we all do stupid things occasionally.  Try "su -; mv -f
> /usr /user; shutdown -r now" and see what happens (actually don't; just think
> about it ;-)

Yes.  And no.... :-)  You're quite right to note that nothing has been
said about the user interface, and also to note that this is largely an
encapsulation of something that is already there.

[Note that I'm not talking about Alexander's proposal here, just mine]

My proposal was simply to wrap files with something that understands their
contents (known through metadata associated with the file) and allows
programmatic access to the contents, like a DOM server does, but extended
to any file type we have a server for.  Being able to understand the
contents of files (or indeed any object) makes it easier to perform
powerful operations upon it in addition to the ones we can perform on the
file.  A master filesystem/object server is responsible for decided what
server to activate for a particular file, and how to access its contents
(as persistent storage, local or remote).  Clients can choose to access
the file, or its interpretation (e.g. as a DOM document).  They can do
this to gain the power of additional operations on a file that depend upon
knowing what kind of data it contains.  Constraining what can be done with
the file is not the intention.

No loss of access at file level was proposed or intended (and would
probably be difficult to reliably achieve anyway). There is not even a
requirement for file accesses to be performed through CORBA or
out-of-process, although it is probably simpler if they are.  We do not
have to throw the filesystem away or change it in any way and could not do
so without massive pointless effort.  Stopping people typing "mv /usr
/user" would not be within the scope of my proposal, and, as other people
have pointed out, might not always be appropriate anyway.

The objective (as I see it) is to move away from files as passive things
that get operated upon by applications (i.e. open application, select
file, do work, save file, quit application), and towards active
persistent objects upon which we work more directly and which support
operations appropriate to their type, giving the potential for more
powerful, more accessible operations and fewer unintended mistakes.  This
is a step towards that.

I know someone will want to point out the role of session management, or
double-clicking a file in gmc to open it.  These things are great, but
largely unrelated to what I'm talking about: programmatic access to
persistent objects which "know" what kind of object they are.

-- Duncan Pierce (D.R.Pierce@soc.staffs.ac.uk)