Re: Moniker critique

[Miguel de Icaza <miguel helixcode com>]

>     I've been studying the moniker's document that Miguel did (at
> http://primates.helixcode.com/~miguel/monikers.html ), and have some
> questions/critiques...

Well it was not clear to me what were your critiques.  Can you please
post a clean list of the specific concerns you have?

>     OK. Don't forget where, when and why monikers appeared first in
> OLE: the COM component model does not have object identifiers: they
> had "interface" identifiers, "class" identifiers, and so, but NOT
> object identifiers... When storing and restoring, it must remember the
> links between component instances (that, strictly speaking, have no
> identifier in COM).

Sure.  That is why there is a section at the end called `The
accidental invention' regarind Monikers.

>     However, in CORBA, this is very different. Objects have their own
> identifier, and by means of a well-configured POA, those references
> can be persistent and universally identifying. On-demand servers can
> be started by means of an IMR-like utility (as is NOT the OAF).

The POA is a demultiplexing request mechanism on a server to locate a
servant.  Monikers are used on the client side.

>     With this in mind, I analyze monikers: In the page, I've seen some
> examples that are very very convenient. Let me show one of them that I
> find really interesting:
> 
> file:logo.png!Zoom=2.0,dither=max,notransparency
> 
> Really funny: an image, with some transformation that can be used by
> any program... However... why this syntax?

This is just an example that on the "object name space" that moniker
implement, the object name space can be as dynamic as you want, or as
static as you want.

> That is, the moniker is equivalent to a bunch of method invocations.
> The "open" method of GenericResourceManager must implement file, http,
> ftp and other request methods (but only traditional URL request
> methods). The different QueryInterface methods of each interface could
> be able to "convert" the object to the desired interface.

For the sake of introducing monikers on the first section of the
document I give examples of stringified monikers.  But the actual
interpretation of them actually depends on the resolution process.
Please take a look at the document later, where I explain how a
stringified moniker returns two different components based on the
interface you resolve against. 

Yes, you can do everything monikers can do manually.

What you are missing is that you have specific knowledge in your
application to decode images now.  In the moniker case, your
application does not care.  

In my case, my app can use:

bonobo_widget_new ("file:logo.png!Zoom=2.0", "Bonobo/Control")
bonobo_widget_new ("http://www.netscape.com";, "Bonobo/Control")
bonobo_widget_new ("config:Gnumeric/Settings:propertyeditor", "Bonobo/Control")
bonobo_widget_new ("trashcan:")
bonobo_widget_new ("ftp://ftp.redhat.com";, "Bonobo/Control")

And they will all return a GUI representation of the moniker that is
embedded into my application.  My application has no knowledge about
images, the web, configuration, trashcans, or ftp sites.

Hey!  And monikers are extensible.  Tomorrow I can create a "miguee:"
moniker that will do some miguee-fication of a something and return a
something else and it will just work with existing applications.

No knowledge about the object exists in my app, nor knowledge about
what they do.  In your example, you do ;-)

> OK. I think that the moniker approach is limited for the future, as,
> for example, it does not exist an interface for listing or describing
> the available monikers, no interface for describing them (some like
> IDL interfaces again!!).  

Well, you can query oaf for everything that is_a moniker.  Dunno if
that is enough.  But the fact that this does not exist barely makes it
limited.  It just means that we must address this issue when the need
for this arises. 

> Bonobo also has an infrastructure for allowing a component implement
> different interfaces, different "views" of the same "thing", and you
> can ask a component what different views it offer
> (interfaces)... why using monikers instead designing flexible
> system-wide interfaces?

Can you give me an example of this?

> Then, IMHO, the point is that it would be better to standarize
> interfaces and to offer a flexible way of "narrowing" sources of
> information based on interfaces. (the same way that .NET does, for
> example). Monikers are somewhat extrange because they are many things
> at the same time, as Miguel points out:

You are confused about the difference between narrowing and monikers ;-)

Essential COM has a good explanation of monikers.  Check it out. 

miguel.