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

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

One good reason for making the file manager CORBA aware is that CORBA
interfaces are going to be implemented for the file manager, the other
GNOME components and the GNOME document model. I think that the CORBA
interface repository and implementation repository might assist in the
design of the file manager. Designing the file manager in another way
may lead to duplication and inconsistency once CORBA is implemented.

The interface repository lists the interfaces that are installed on the
system. Each GNOME aware application is going to implement at least one
interface. This interface will effectively describe the things it can do
to files (along with other details).

The implementation repository links the interfaces in the interface
repository to the means used to activate them. Thus the interfaces in
the respository can represent abstract capabilities which become linked
to specific servers by the implementation repository. This provides an
analog to the mapping from file types to applications.

It is difficult to be specific about how the repositories might be used
by the file manager without knowing the kinds of interfaces that the
applications will export. However, we can consider a concrete example.

Let us assume that the file manager exports an interface which allows
file names to be viewed using CORBA:

file_view.idl
-----
interface file_view {
	void view(in string name)
}
-----

(I am not suggesting this is a particularly good interface).

This interface would be registered in the interface repository when the
file manager started up. At the command line in mico one could use:

	idl --no-codegen-c++ --feed-ir file_view.idl

The file manager would be responsible for determining the location of
the file and examining its contents (meta-data, whatever) to try to
determine the type of the file. 

If it discovered that the file was an image then it could look up the
default application for loading images in a database and start it up. 
Alternatively, it could use CORBA to do this part of the operation.
This would operate as follows:

1) GNOME applications which could view image files would export their
   CORBA interfaces. These interfaces might include a file_image_view
   interface: 

	interface file_image_view : file_view {}

   Similar interfaces could be registered to represent other mime types
   (or whatever). 

2) A server for the file_image_view interface would be registered in the
   implementation repository. This server could be a library, a running
   application or a remote server. If the server were an application
   it might be registered as follows on the command line in mico:
	
	imr create EE permethod '/usr/local/bin/ee' \
		'IDL:file_image_view:1.0'

   In practice GNOME would want some sort of graphical interface which
   manipulates the implementation repository. Something like the 
   Edit/Preferences/Navigator/Applications dialog in netscape.

3) Once the file manager kenw the file was an image it would create a
   file_image_view object and invoke the view method. CORBA would
   handle the translation of this action into an invocation of ee.

4) Applications which did not speak CORBA could be invoked through a
   CORBA proxy shell which would collect the arguments and assemble
   them into a shell command.
	
An application could obtain a reference to the subclass of file_view
that needs to be created to view a file from the file manager and then 
create a view of that file at a later date without the file manager
becoming involved.

Note what is happening here. The file manager and GNOME application have
registered their interfaces. One of the GNOME applications has been
assigned as the server whihch implements a specific interface. All of
this is essential to get CORBA working (in a dynamic environment). 

As a result of the forms of interface that were registered we have
obtained a mechanism for mapping from file types to applications that
can also invoke library plugins and running or remote servers.

Of course, you could implement the mapping for the file manager using
another (less powerful) mechanism but why would you want to when this
one comes out of the wash once CORBA is implemented?

----

The above implementation only establishes the default map from file
types to applications. The possibility of viewing or opening files in
other applications would depend on the file manager searching the
interface repository to find alternatives and then listing them.

I am not quite sure about this bit of the implementation but this may
work: applications which can view image files might include a
file_image_view interface within a module of interfaces that they
export:

module ee {
	interface file_image_view : File {}
...
}

module gimp {
	interface file_image_view : File {}
...
}

The file manager would skim through the repository, pick up the modules
with file_image_view interfaces and present the user with a list. When
one was selected the relevent onject would be created and invoked.

Note that since the interface repository is saved as an ascii file in
IDL it is relatively to examine what is available from the command line.
However, CORBA provides searching methods which should make these
operations quicker than a search though a mime.types file.

----

Now note the scope for extension: applications (and other servers) can
add other methods which the file manager can pick up with equal ease.
There is no particular reason to stick to open and view. Any conflicts
between the facilities offered by different applications are handled by
the module reference or the implementation repository choosing one over
another.

----

Further extension arises when we note that what the file manager is
finding files, typing them and then creating a CORBA object from them.
This process can be extended to producing CORBA objects which do not
correspond to files. 

This would be useful on the desktop where objects representing printers,
users, hosts, etc. could be produced. However, I think this area would
take some time to develope.

----

It is difficult to be definitive about the advantages of this approach.
Using CORBA may save on the development of some databases (but requires
the use of proxies for non CORBA apps). Using CORBA allows you to invoke
methods that are not implemented as local applications. Using CORBA
offers one way to tap into the functionality that applications have
registered on the system automatically. 

The capacity to extend the file manager in new directions has benefits
(and possibly costs) that remain basically incalculable.

----

The time scale for this implementation depends heavily on the time taken
to establish the CORBA interfaces to the GNOME components and
applications. What I have suggested is that it is possible to solve the
file type to application problem using CORBA providing those interfaces
are designed in appropriate ways. I doubt the design I have proposed
here is anything like the best way to do it using CORBA.