Re: Libole2.

[Miguel de Icaza <miguel helixcode com>]

[ 
  Please note that I am not saying Nautilus or file-based apps should
  use monikers for doing their file IO.  That is a separate issue.

  I was just explaining and introducing the concept of monikers, and
  why I think we can do a lot more by having a robust moniker
  interface than we can with a file intereface
]

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

Lets start simple.  A moniker is a reference to an object[1].  To
actually use the object, you have to "resolve" the moniker.  The term
used in the literature is "binding the object".

The result of resolving the moniker is a Bonobo::Unknown object.  

Think of a moniker as a pathname.  And think of the binding process as
the "open" system call on Unix. 

		     Unix Files 	           Monikers
	            -----------------------------------------------
Object naming:       path name                moniker string representation.
Binding function:    open(2)                  bonobo_get_object
Return value:        kernel file descriptor   Bonobo::Unknown CORBA reference
Binder:              Kernel VFS+each FS       bonobo_get_object+Bonobo::Moniker 
Persisting:          none                     Moniker::QI(Persist)

In the case of the file system, the kernel does the "resolution" of
each path element by parsing one element of the file system, and the
Virtual File System switch uses the current file system + mount points
to resolve the ultimate file name.

A Moniker provides a ::bind_to_object method.  Typically, the system
will provide a few predefined Moniker names that know how to implement
::bind_to_object.  There are three major classes that shipped with the
initial implementation (this is inacurrate for the sake of this
explanation):


	File Monikers: binds a file name to a component.
	Item monikers: binds an arbitrary object with a name of the form [a-z]+
	Composite monikers: composes moniker A + moniker B and returns moniker C.

Other monikers can be provided by your application to suit your needs,
other can be provided by the system.  The only important step is that
they implement ::bind_to_object.

Now, given a moniker that points to an object, you can request it to
dump its representation in a string format.  This is what you saw in
my previous example, a stringified version of the moniker.

The fact that for my example with an url it looked like an url is
merely a coincidence.  The driving motivation is not "build a generic
system on top of the url naming scheme" but rather the fact that you
can point to arbitrary objects.  The stringified version can be
anything.  If we decide that looking like a url and not being a url is
bad, then we coudl have something like:

	("http" "www.helixcode.com" "sales.xls" "graph" "background")

As the moniker output.  It really does not matter.


The parsing of a moniker stringified representation is done by each
moniker implementation.  How this is implemented, is up to each
moniker.  

Miguel.

[1] Now here is what might be causing confussion: It is not a
reference in the traditional CORBA sense.  It