Re: Libole2.

[Miguel de Icaza <miguel helixcode com>]

> Actually, this sounds _less_ powerful in some key ways. What if you
> have a data resource that can be handled by multiple different
> objects? 

How is that less powerful?

I think you are thinking here "file", and we can picture say "GHex"
(an hex editor that edits files) and GIMP (a paint application).

They both want to access the files, and you find yourself thinking
"Geez, how can I use them both".  Well, the answer is that you use a
shorter url that stops at the file level, and then you use the
resulting File interface.  Does that make sense?

Outlook and Office applications on Windows use this mechanism to
stream themselves into Exchange servers for storing their contents.
They do not have real "file" access.  They do not use the OS file API,
they use a moniker-based file IO system. 

Lets take an example (again for the sake of this explanation, lets not
fight about whether it is good or not to use url notation or if the !
is more evil that % or not):

This is something that can be done in COM+ these days [1]

   http://www.helixcode.com/e-commerce?account=miguel

I could use the above object to manage the "miguel" account:

   ref = "http://www.helixcode.com/e-commerce?account=miguel"
   miguel = bonobo_get_object (ref, "Account:1.0");  [See note 2]
   account_add_product (miguel, "Laptop", "3000 USD");

But lets say the terminal is operating in disconnected mode, the url
changes to:

   ref = "queue:http://www.helixcode.com/e-commerce?account=miguel";
   miguel = bonobo_get_object (ref, "Account:1.0");  [See note 2]
   account_add_product (miguel, "Laptop", "3000 USD");

The queue moniker will delay the instantiation of the remote
component, and return a proxy object that stores all request sent to
that object, and flush those requests when the network goes up.

This is not a theoretical example, this has been part of the MTS
system and it has now been integrated into COM+ as a single package. 

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

Making a choice is a separate problem.  That very problem we have
anyways and we have to solve for other applications.

Can you present a concrete example of why this is a problem, or what
problem you are thinking of?  Because I am failing to see it.


[1]  (just because they added a new moniker handler):

[2] Previously I failed to mention that bonobo_get_object will take an
    interface to pull at startup time from the component.  I can
    explain why, but lets keep it simple for  now.

Miguel.