Re: Moniker critique

[Rodrigo Moya <rodrigo ulises openresources com>]

> I would like those more than monikers... restrict monikers to specify location (as
> URLs), and let standard APIs do the rest. Note that you don't loose expression
> power as you are using the same standard interfaces (Control and so on).
> 
> I'll try to explain myself even more. Let's take again the next moniker:
> 
> file:logo.png!Zoom=2.0,dither=max,notransparency
> 
> The "generator" of the moniker (the one that produced the string representation)
> knows that:
> 
> 1. It is a file
> 2. It has the png extension
> 3. wants to zoom it and apply some other transformations...
> 
> So, I'm going to explain what it could be done with this information:
> 
> The "generator" can use the System-provided "System::File" interface to open the
> file. It can rely on an API that maps the file extension to a mime type or a
> component factory that handles this type of mime content. In this case, to handle
> this image, a eog_component's server will be launched, returning a system-provided
> "System::Image" object that can be used as such.
> 
> The generator can then manipulate the image as needed following the
> "System::Image" protocol (it must know that it is an image... if not, it could not
> produce the moniker that zooms, etc the image) and then returning the IOR of the
> resulting modified object to the "receiver" of the modified image... The
> eog_component server is in charge of assuring the persistence of the modified
> image, and what the "generator" passes to the "receiver" could be a
> "Bonobo::Unknown" object, that again can be asked for a "bonobo/control"
> interface.
> 
This example shows IMO the need for specific interfaces. As I've understood

from what I've read about monikers, they are great for getting
components which implement
"generic" interfaces (Bonobo/Control, Bonobo/Stream...), which are great
for most needs, but there
may be times when you want to
be able, for example, to call an Image component which lets you make all
sorts of transformations 
on an image (change its colors, rotate, ...). This is an example of a
very specific component related to graphics manipulation, but the same
applies to other system services, such as the system's MTA,
system configuration, package manager, network services (DNS, whois)
etc.

Of course, all this can be implemented right now in other non-Bonobo
ways, but having all this in
Bonobo would be great, since it would offer a big functionality to
"client" apps. I would start by
creating a new module called bonobo-services (or whatever) and write
some IDL.

cheers