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

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

Larry 'Daffy' Daffner asked:

>> What's we're specifically aiming for is a _per-file_ ability - so
>> I can set 'less' as the viewer for .log files, but
>> 'draw_pretty_graph' as the viewer for the
>> /var/log/httpd/access.log file, as an example.

Miguel de Icaza replied:
  
> The GNOME file manager already does this.
> 
> You would do:
> 
> shell/*.log
>  Open=draw_pretty_graph %f
>  View=nxterm -e 'less -f %f'
> 
> The "shell" tag means it should use shell-like filname
> matching, you can use that or use full regexps our classify by
> file type (by running the file command and matching the output
> of file against a table of known types).

Larry was enthusiastic about this response but wanted to consider
ways of extending the file matching mechanism, ...

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, ...).
The mechanisms for invoking this functionality are class dependent and
could potentially make it all the way down to a class containing a
single file object (e.g. operations on / and ~/).

Why are we debating how to do this? I thought GNOME was a 'Network 
Object Model Environment.' There is a standard interface to network
objects which GNOME is already committed to using: CORBA!

GNOME has expressed an intention to use CORBA to implement its document
model. 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? 

The design of the file manager will play an important role in deciding
which of these possibilities becomes realised. 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. Desgin the file
manager to provide a flexible GUI to (almost) any IDL made available by
a "document" class and CORBA has a field day! The file manager becomes
a host for ARBITRARY plug ins. You can even abstract from the file 
system itself ... include documents representing users, hosts,
processes, cyberpets ...

Sounds far fetched ? Well, mico includes an interface repository that
can store the class heirarchy. ORBit will include one eventually. Mico
has a java interface to its repository which is largely text based but
very general (you can invoke any method on any interface). It would be
fairly straight forward to devise a more attractive interface to 
any methods that are invoked without arguments (menu items). Drag and
drop provides a means of specifying single arguments ...

To implement the file manager you need IDL for base file and directory
objects. However, most file operations (new, delete, etc.) are generic
to all objects and already CORBAservices. Therefore, you might as well
implement an object manager which opens container objects instead.
How is that for a virtual file system?: it seemlessly spans address
spaces, file systems, hosts, the internet.

Within this overarching framework, directories become a class of
container object which contain files. The generic file is just an object
contained in a directory. The IDL for a file object includes a method
to determine the specific type of each file which could be implemented
using recursive file magic (i.e. once the file is know to belong to a
class then the IDL for that class would provide a means to further
subclass the file). The IDL for the type of the file would determine the
operations that the GUI would make available to the user.

This mechanism allows any heirarchy of file types to be defined using
any language at any level and provides any method interface to the final
files. Is that what Larry wanted?

Given a good implementation of CORBA, this should be an efficient 
approach. ORBit currently accomodates invocations over an IP link but
there is no reason why CORBA invocations should not be made to shared
libraries almost as quickly as C function calls.

Give the user a guile compiler for IDL and incorporate an object
representing the user into the mechanism used to determine file types
and then the user can redesign the class heirarchy in arbitrary ways.
Hackers can come up with a variety of GUIs making this easier.

I am interested in developing a GNOME GUI to the CORBA interface
repository. I think this functionality should be integral to the GNOME
"file" manager. Any comments?

Felix