Re: Continuing discussion of oaf ...

[Michael Meeks <michael helixcode com>]

Hi Martin,

On 27 Nov 2000, Martin Baulig wrote:
> >         * We already have a clean namespace, that has at least as many
> >         interfaces as implementations [ cf. the number of interfaces
Excel
> >         exports and the number of implementations (1) ].
>
> I don't think this is true in whatever way you read it:
>
> "that has at least as many interfaces as implementations" -
>
>         That's already wrong when two components implement something
like
>         IDL:Nautilus/ViewFrame:1.0.

        Simply because components A and B implement interface Q does not
mean that either of them cannot be also implementing interfaces
R,S,T,C,G,V etc.
        
> "that has at least as many implementations as interfaces" -
>
>         Harder to proove that this is wrong, but the fact that you're
> allowed to write and install an .idl file without actually implementing
> it should be proof enough.

        I don't understand the proof. What I am maintaining is that there 
is, and should be an approximate parity between interfaces and
implementations, and while on one side we have the 'panel applet' type
component, on the other side we have the Excel like component that
implements badzillions of complicated interfaces, and is a single
implementation.

        I state this because there are some that say we need a greater
level of uniqueness amongst implementations than interfaces. Clearly I
agree with this for some cases ( eg. panel applets ), where the UUID is
most appropriate. However, I think this is a fringe case.

> However, I think we can assume X < Y long-term if X is large enough -
> so we will have more implementations than interfaces.

        I look forward to this prediction coming true. eg. examine the
number of Open Office interfaces; I count: 1972 idls ( ok so some fraction
of these will be service contracts ), but lets say that 1/2 are services
so we have 1000 interfaces; lets say we split Open office into OCalc,
OWriter, OBase... say 10 separate implementations; this is 100 interfaces
per component approximately.

> You misunderstood me. According to my proposal, the UUID is an
> essential and required part of the component naming scheme and you
> cannot leave it away neither in the .oafinfo file nor in the factory
> implementation function.

        Why is it essential ? I understand your desire to make activation
easy; indeed we all want this. But I am having increasing problems in
seeing any useful purpose in keeping the magic number if we are not going
to activate by it.

        Put another way; what possible conflict does this extra magic
number remove for us; or another way, what effects will this conflict
have ?, or perhaps, how is this conflict different from installing the
same oafinfo file in 2 parts of the oaf path ? or again, how does having
this number help anyone ?

> I just suggest that it should be allowed to use the short form
> (without the UUID) when _activating_ an object - so, technically,
> this'll be an oaf_query for a component which has an OAFIID which
> starts with that name. If there'll ever be a conflict in the short
> form, oaf will just choose one of them (with the possibility to
> specify which one in a config file).

        I do not see how possibly a conflict could arise here with a
correctly namespaced name. And furthermore, if there was a conflict I
don't see why we would want a text file to disambiguate it instead of   
fixing the components with the conflict.

> You need to cut and paste these strings anyways, so there's no
> difference.
 
        I don't need to cut and paste OAFIID:GNOME_Gnumeric or whatever.

        Either way; the summary question is this:

        What makes you believe that eg. Ettore is not competant to
allocate names within his GNOME_Evolution_ namespace, that do not clash
with other names he has allocated ?

        Or conversely; what makes you believe that eg. George is not
competant to make simple applets use a UUID based scheme before committing
them to gnome-applets / core ?
        
        Regards,

                Michael.

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