Re: Libole2.

[Maciej Stachowiak <mjs eazel com>]

Miguel de Icaza <miguel@helixcode.com> writes:

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

Well, at minimum the filesystem-based storage back end should be
replaced with a gnome-vfs-based one. Also, it would be great if
libole2 and libefs could be hacked to able read from a gnome-vfs URI
rather than just a file, to that bonobo could transparently handle

Also, gnome-vfs modules for libole2 and libefs are nice even
independent of using them for bonobo, for pretty much the same reason
modules for tar, ar, zip and such are.

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

Miguel, I'd really like it if you explained monikers to me in detail,
or better yet, pointed me to some useful reading material. You and
Mathieu keep saying how great they are, and how they are inherently
more powerful than URIs, but I don't understand why.

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

Actually, this sounds _less_ powerful in some key ways. What if you
have a data resource that can be handled by multiple different
objects? What if I want to make the choice of which to use based on
application-specific user preferences, or let the user change the
choice of object to use at run time? Basically this breaks
model-view-controller separation - you can't get a reference to the
data resource itself, only to one particular object that thinks it
knows how to handle it.

> 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

Obligatory whining about standards: Using ! in a URI like that is
wrong; you shouldn't put anything in a URI that can't be resolved by
the server. If you have a URI reference that needs additional
client-side processing to resolve, probably the right thing to do is
use a `#' separator. Unless monikers aren't supposed to be valid URIs,
but merely things which look almost exactly like them - which I also
think is bad.

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

What if I have more than one program on my machine that can handle the
spreadsheet? Maybe monikers solve this problem but it doesn't sound
like it to me.

 - Maciej