Re: Moniker critique

[Michael Meeks <michael helixcode com>]

Hi Diego,
        
On Thu, 7 Dec 2000, Diego Sevilla Ruiz (dsevilla um es) wrote:
>     First of all, I think that monikers are not the future: components 
> are. Let me explain what I'm trying to say and discuss, that is what
> this list is for.
        
        But wait, components and monikers are fully orthogonal; surely?
        
>     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).
        
        Surely an instance is just a matter of getting a class by its
identifier and doing a CoCreateInstance (IIRC).
        
>     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 a simple stringified syntax that passes effective
'construction time arguments' to the object. It is simply adding Zoom,
dither and transparency axis into the pan-dimensional virtual object space
and then selecting one object from this space ( jargon hey ).

        Clearly you can do this all as separate methods; still you can
construct this standard unix pipeline as a set of methods:

        rpm -qa --queryformat '%{NAME}\t%{SIZE}\n' | sort -n +1
        
        The rpm command fires up an instance of the rpm 'object' :-) that
is initialized to a certain state by its arguments and then this is
connected to sort. So yes, this could be done as:

        r = get_rpm_object ();
        r->setQueryAll ();
        r->setQueryFormat ("%{NAME}\t%{SIZE}\n");
        output = r->execute ();

        s = get_sort_object ();
        s->setByNumber ();
        s->whatever+1Does ();
        s->input (output);  // what a great line  
        output = s->execute ();

        out (output);

        Or whatever; but this is not such a succint, flexible, powerful,
re-usable paradigm. In fact monikers whilst similar to pipes are far more
powerful, and fully bi-directional at each stage.
        
> IF WE WERE USING A SCRIPTING LANGUAGE, note that the moniker
> identifier could be substitued by:
> 
> ---------------------------8<------------------
> myImage
> =
GenericResourceManager.open("file:logo.png").QueryInterface("Stream").QueryInterface("Image");
        
        It seems what you're trying to do here is to express a moniker as
an expression. The problem is that QueryInterface doesn't do what you seem
to imagine. To duplicate the Moniker's functionality you need to fully
unroll what the moniker is doing which is this [ unpacking and simplifing
the recursion ].

        Stream s = open ("file:logo.png");
        MimeType t = getMimeType (s);
        Unknown o = doOafQuery (has mime_type==t && implements IDL:Image);
        Image myImage = o.queryInterface (o, "IDL:Image");

        and then:

> myImage.zoom(2.0);
> myImage.dither(max);
 
        I would argue that while both approaches produces identical   
results the moniker method is more beautiful, flexible and elegant :-)

> ---------------------------8<-------------------
>
> That is, the moniker is equivalent to a bunch of method invocations.

        You missed the data; a moniker is state-full description ( the
arguments in your code ). So, we have state and processing, who's going to
write the first fully moniker based calculator ?

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

        Well I see what you mean; it would be possible to develop a method
as you suggest that might be able to do this, however we still need
monikers for cut and paste and transfer of opaque object location
information, and ( in the future ) standards conversion of object
referencing etc. etc.

> 1. a naming scheme for objects (CORBA objects have IORs, whose
> ObjectIDs can be also hierarchical)
> 2. processing instructions (which are not necessary, if we use
> standard interfaces and APIs)
        
        Yes; a moniker does a number of things. The thing is that I see
the processing instructions as merely extra axis in the object namespace,
and not a separate issue.
        
> 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!!).

        It is hard indeed to provide an interface for enumerating the
elements of an infinite namespace :-) this is part of the power of
monikers.

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

        I'm not sure that I understand what you propose instead in the
form of flexible system wide interfaces. If you are basing this on the
example of eog's image and setting up parameters. Yes; it is important to
have nice IDL interfaces for programmers, and yes I agree that in many
cases it is important to be able to programmaticaly do all that you can   
with monikers via. the IDL; however, there is no need to not use the
trivial moniker to do it for you. Monikers are the root of cut and paste
functionality, and unless you suggest serializing this stuff as a series
of textual program code to be executed to re-create the link [ something
security people would not be over happy with :-] ( which would just be
another moniker representation BTW. ) I don't see what you suggest.
 
> That were all my thoughts. I hope I knew explain them all OK.

        I don't think I understood them all; but please do elaborate
further.
 
        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot