Re: Libole2.

[Maciej Stachowiak <mjs eazel com>]

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

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

Not quite. If I have an embedded image inside a Spreadsheet document,
I still want to be able to use my choice of components to view
it. Similarly, if there is an embedded graph and I have multiple
components on my system that know how to process the graph data, I
want to be able to do the same thing. Another example: if I have some
kind of data embedded in an email attachment

Basically, 

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

Those look like cool hacks, but that example seems pretty much
designed so that there is one and only one object that makes sense at
the other end of that URI. I think that for many desktop applications,
that will not be the case with the data they manipulate.

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

Well OAF (and the way Nautilus uses it) do a lot towards that goal
(side note - an ex-MS employee told me recently how much cooler he
thought OAF was as a way to get objects with particular capabilities
than the Windows Registry). You can get the set of components with
particular capabilities and provide conditions to sort by. You can
either let OAF choose automatically based on your criteria, or process
the resulting list yourself however you want (applying user
preferences, etc). But this is only possible because you can get at
the raw data (the mime type, the URI scheme, and so on) _before_
activating an object on it, so we can determine what objects are
capable.

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

Some examples:

* When you view a location in Nautilus (and we want to be able to
manipulate and link to sub-file objects, so if I have something
embedded in my spreadsheet I can link to that in my homedir for
instance), Nautilus determines the mime type, looks at the URI
protocol, and does an OAF query to determine the applicable
objects. It lets you select from them with the "View as" menu, picking
a default from user preferences and pruning the list using
preferences. If the location happens to be pointing to an embedded
subdocument rather than a "file", I want to be able to handle it as
close to the same way as possible. So basically I need to be able to
get the raw data the location (whether it is a moniker or a URI,
whatever) and be able to choose myself what component can handle that
data.

* You should be able to configure what component gets used when you
get an email attachment in Evolution. Maybe it would also be useful to
be able to change this choice on the fly.


* In a compound document application, you may want to keep an element
with the same data but handle it with a different component, in a
response to a change in user preferences.

* I am not quite sure how much this one applies. In a compund
document application, when you paste data out of another application
you may want to use a different component to handle it than the
original app did.


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

Why do you want to do that instead of getting a Bonobo::Unknown and
doing a query_interface as usual?

 - Maciej