Re: Libole2.

[Miguel de Icaza <miguel helixcode com>]

[ 
  This was a private conversation between Michael and me talking about
  libefs, libole2 and the integration into gnome-vfs.  
]

> 	  ie. in due course I want to move libefs and libole2 into
> GnomeVFS, and make a BonoboStorage map to a GnomeVFSURI [ or sim. ],
> this will allow a huge degree of inherited power I think, including
> the ability to save to PKZip format as an added [..]. Also it will
> hopefully allow transparent use of libole2 / e2fs / whatever which
> would be nice.

I am not sure moving them into GnomeVFS is the right thing to do.  For
one, I think that using the GNOME VFS for implementing storages is a
broken idea.  

Not only that, but these days I am convinced that naming objects
should not go trough the GNOME VFS, but trough the moniker interface.
Once you are finished with your studies I can explain to you what
monikers are (not our current lame implementation, but the full one
that me and Mathieu will be working on) so that you see how irrelevant
gnome-vfs becomes.

Sure, having gnome-vfs handlers will be "useful", but really, monikers
are way more powerful than file access to an object.

> 	  Hence, I'm not just trying to create problems randomly =) what do
> you think of my mental meandering ?

I think that we need to sync up on the vision of monikers :-)

basically, with a gnome-vfs interface what you have is a "name" (the
url) that when "resolved" provides a file or a directory interface to
the resolved object.  For example: Open, read, close, write, seek,
etc.

This is fine if you care about accesing these names as files (like for
a file manager, or like applications that need to load files)

But this is a very narrow view of the whole problem, and Bonobo can
solve this in a more elegant way.  Actually, it can solve this in a
perfect way.

With monikers, names identify objects.  So your name (what gnome-vfs
uses are the "url") does not actually resolve to a thingie that
provides a file or a directory interface, but rather, it resolves to a
beautiful Bonobo::Unknown object reference.

The process of resolving the "name" can hook up arbitrary activation
mechanisms during the resolution phase.  Each "element" of the path
is resolved by its own moniker component (a few will be provided as
part of Bonobo).

Various moniker resolving mechanisms can be registered in the system.

For instance all of the GNOME VFS access routines for files can be
encapsulated by providing resolvers for the same prefixes that
Gnome-vfs supports right now (file, http, ftp).  But the story does
not end there. 

Say you have a reference like this:

	"http://www.helixcode.com/~miguel/sample.xls!Graph1!Background

The moniker binding process will resolve the entire object in there:
from transfering the file, to launching gnumeric, to launching the
graph component, to return the referece to "Background" which
implements Bonobo::Unknown, and which might be in this example
implement the "Color" interface.  

So you could write code like this:

	object = bonobo_get_object (uril);
	color = bonobo_query_interface (object, "Color:1.0");
	if (color){
		printf ("The color is: %x\n", color_get_as_hex (color));
	}

Miguel.