Re: Moniker critique

["Diego Sevilla Ruiz (dsevilla um es)" <dsevilla ditec um es>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all!:

    Sorry for answering too late... but I've been very busy. First of all, note
that my first intention is not to be rude, but to offer another view... I'll try
to explain myself a little more.

    From the above discussion, if anybody followed it, I want to raise the two
most important questions:

1. Monikers are stateful representation of an object, and are an essential part of
cut&paste operations. Also Miguel said:

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

And I wonder... what is the representation in CORBA of a (either stateless or
statefull) object? IT IS AN IOR. So, an IOR:

a). Can be used as a reference to a (possibly stateful) CORBA object. The server
implementing it is the responsible for its persistence.
b) Cut&Paste operations can pass IOR references to objects.
c) POA is of course of server side, but you can organize your server's POA in such
a way that will produce hierarchical ObjectIDs, that, as you know, are included
inside IORs and can be given to the client. So, IORs can also be used from the
client perspective to name a specific object. (as monikers do)


2. The other question was that of "system wide flexible interfaces", that seems
not to be very clear... I'll take some more examples:

You say some monikers:

trashcan:

I say:

a) Define a System::Trashcan (system-wide) interface of which you can obtain its
unique instance:

System::Trashcan.getInstance()

This will return a Bonobo::Unknown object.

b) Ask to it if it supports the "Bonobo/Control" interface:

control = System::Trashcan.getInstance().queryInterface("Bonobo/Control");

Another moniker:

oafid:whateveridyouimagine:new:

I say:

a) Define a System.ComponentActivator:

ca = System::ComponentActivator.getInstance();

b) Ask it to create a new object of the specified identifier:

o = ca.new("whateveridyoucanimagine");

This, again, returns a Bonobo::Unknown object that you can use as above

OK. From now on... can you imagine thousand of new System services and
interfaces? Files, Streams (from files, http connections, etc,etc), and so on?

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.

The receiver, in a cut&paste operation, for example, will receive an IOR of an
object. It can try to narrow to a Bonobo::Unknown, (that will succedd), and then
as it for the "Bonobo/control" interface, effectively obtaining the same
functionality that monikers give, but based on System-wide standard interfaces.

    Hope this make my ideas more clear... if not, forget it all about ;-)

    Regards.
    diego.

Miguel de Icaza wrote:

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



--
Diego Sevilla Ruiz -- http://ditec.um.es/~dsevilla/ -- dsevilla um es
       Departamento de Ingeniería y Tecnología de Computadores
           Facultad de Informática. Universidad de Murcia
Campus de Espinardo  -  30080 Murcia (SPAIN).  -  Tel. +34-968-367658
PGP:  http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xC9B964B7
\huge d\em\kern-.36em\lower-.2ex\hbox{\small sevilla}\kern- 1em um es
perl -e'$_="\x4\ FLe\x2&B";for(/../g){print unpack("b*",$_),"\n"}'|tr 01 " #"




-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: mk36VNM5VJnYbwOggnzUh2EAx2wqf7Xr

iQA/AwUBOjU6g9oq0AfJuWS3EQIBcgCgxJsNT2o/FUwWjzDX4/jx32yPLskAn1BA
10TMX2zJALcKIXKr8gYry/7J
=44/a
-----END PGP SIGNATURE-----