Re: [Summary] Meta-data/filesystem-encapsulation

[Felix Bellaby <felix pooh u-net com>]

>
> > Design the file manager to accomodate "open" and "view" and limit
> > the class heirarchy to mime types and you are heading for a crippled
> > CORBA.
> 
> I do not see the connection between a document model and the file
> manager here.  I am sorry, but I really cant figure out what role does
> the file manager play in my spreadsheet nor the word processor.
> 
> I am starting to believe that you and I are thinking of very different
> things.

The difference between us is in where we conceptually place the
functionality of the computer. Existing desktop environments place this
functionality within applications. I am suggesting that it resides
within objects and files are objects.

My position is obviously an abstraction from the realities of executing
binaries. However, it makes sense. Programmers are used to object
orientated abstractions and GNOME is full of them. Ordinary users are
concerned with operations on documents and find the dependency between
documents and applications a real pain rather than a help. When working
at the command line we use utilities (awk, gcc) as operations on files
rather than jumping between application environments. With object
embedding existing applications are increasing trying to obscure their
own existance. I do not think applications are long for this world.
Would you mourn their passing?

If we place the functionality of the computer within files as objects
then a much wider world of possibilities opens up. I think CORBA, java,
the WWW, ... are pointing us in this direction.

In this new environment the file manager can not just manage the
directory tree and post the objects off to applications. It needs to
present the user with a picture of what functionality each file
provides. This means integrating the document model into the file
manager. This is already implicit in the distinctions between the icons
for directories, executables, etc. What I am proposing is that as much
of the functionality of the object should be available from within the
file manager as possible. 

This brings us near the environment that we enjoy in the command line.
However, I think it would be an improvement because with CORBA you have
access to a wider field of objects and the opportunity to use
inheritance (not that that is necessarily always a good thing).

Why put access to object functionality into the file manager? Why not
leave it within applications? Does this need an answer? One might as
well suggest restricting access to the command line.

Of course, the benefits of this approach would be small to start with. 
There is no great pool of IDL servers out there that it would be nice to
be able to access. However, as the GIMP illustrates once you create an
environment which promotes the writing of plugins they start pouring in.
More importantly, by using CORBA and providing OpenDoc methods you make
these plugins generic.

The GIMP should be providing the model for the GNOME file manager. Of
course, all the objects in the GIMP are images but otherwise you get the
idea. Let us put a procedure database in IDL at the heart of GNOME. That
is the route to developing an object environment. The GNOME components
would be important objects within that database but the stuff that grew
on top of them would be the real joy.

By making the document functionality immediately apparent to the user
and available to languages with IDL interfaces (should include guile)
you will produce a very open environment. One of the problems with
document / view models is that the interfaces remain obscure. In the
environment I am proposing the interface has to be comprehensible to the
user. Tough luck on hackers who make life difficult for one another.

An important point to note is that this is in no way inconsistent with
supporting applications. Indeed, to start with the only methods
available on most objects would be "open me in application x", ...
The point is to accomodate the extensions.

Felix