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

[Miguel de Icaza <miguel nuclecu unam mx>]

> What this discussion illustrates is the need for an object model       
> behind the user interface to the computer data space. The file	       
> manager accesses file objects. There are a variety of classes of       
> file object (file/image, file/binary, ...) and these classes have      
> subclasses (file/image/jpg, file/binary/GNOME, ...). Each subclass     
> inherits functionality from its parents (delete from file, ...) and    
> has functionality of its own (edit for image, execute for binary,
> ...).

You think it is an object model because you want to look at it as if
it were an object model for these file objects.  

> How does it intend to do this ? Will there be a single interface
> for "documents" and a single interface for "views"? This would reduce
> CORBA to a network protocol embodying a small API (like the small API
> for applets and panel). Or will it define a heirarchy of classes which
> allow hackers to come up with new subclasses of document and new
> subclasses of view? 

There will be a set of interfaces that describe the various
interactions of the componets in various scensarios.  You are free to
extend them to suit your own needs, sample implementations will be
provided as part of the Baboon libraries and you can extend those,
override them or reuse them as you see fit.

Ala, this is hardly connected to files in the file manager :-).

> 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.

Miguel