Re: Oaf names & file structure

[Mathieu Lacage <mathieu eazel com>]

hi all,

Michael Meeks <michael helixcode com> writes:

> 
>         You object to me and Miguel doing the job ? I agree the foundation
> should own the namespaces ( if we can register them at all ), and deal  
> with any difficult situations, but I see this process as just a rubber
> stamping excercise mainly.

Well, life sucks but I agre with maciej on this point: the foundation should
own the namespace and its allocation.

> 
> > >
> OAFIID:GNOME/Evolution/Shell/Factory:[123-234-34-3245-2345-345-345-324-234-122-1342-34-234-3245-24356-345-34-57-35634-6-356-2456-345-234-34-23$
> $> >         The optional number / string being for those who are paranoid
> > > about 'uniqueness'.
> >
> > It looks like you're using a naming scheme based on IDL interface 
> > names. This makes no sense because IIDs are _Implementation_ IDs, not
> > _Interface_ IDs.
> 
>         I am basing my suggestions on my understanding of what happens in
> the Microsoft world. In this case every interface is named with a number,
> and AFAICS these same numbers are used to activate
> components; cf. CoCreateInstance / CoGetClassObject.
> 
>         Of course; I prefer a consistant scheme across interface naming
> and activation, so perhaps we should not bother with namespacing ( which
> seems contentious ), and go with naming all our interfaces with a uuid, 
> eg.
> 
>         IDL:7729c846-2f6c-4ebf-b36f-01de85ee2faf:1.0
> 
>         and having a load of defines around the place for these ?
> 
> > In Nautilus, we have a bunch of components that would
> > all be named "OAFIID:GNOME/Nautilus/View" based on your
> > scheme.
> 
>         Grief; perhaps you didn't understand my scheme; I'll expand it
> again for you with another ( similar ) example:
> 
>         OAFIID:GNOME/Evolution/Mail/ComposerFactory
> and     OAFIID:GNOME/Evolution/Mail/ComposerComponent
>           
> or
> 
>         OAFIID:GNOME/Evolution/Mail/ShellFactory
> and     OAFIID:GNOME/Evolution/Mail/ShellComponent
> 
>         etc.etc.etc. NB. none of these exist as interfaces; it is simply
> the use of the namespace to generate a unique ID.
> 
>         ie. using our reserved portion of the namespace to create an
> IDL-like name that uniquely identifies our _Implementation_, in the same
> way that the oafinfo filename uniquely identifies our implementation. 


It is funny, I see this same topic coming here again and again, over and 
over again... It is kind of tiring. I thought that last time we had reached
a concensus.

> 
> > However, the portion before the colon is a free text string according
> > to the current recommended standard format for OAFIIDs, so you are
> > free to use this however you want. The UUID is not optional in the
> > recommendation.
> 
>         I see no need for the UUID at all; it is impossible to remember 
> and type in, and there is no need for it, unless that is you think people
> cannot be trusted to use their namespace wisely to create unique names ? I
> would far, far rather be able to have a memorable ID than some impossible 
> to remember number. [ it took me long enough to memorise my social
> security id ].

Applications should NEVER EVER use IIDS directly. OAF is something which was
designed precisely so that you do not have to remember to keep them around.

there is an api funciton you know very well which is called oaf_query
and it is made so that you make a query to get the component you want.
Using the IID directly has a number of problems among which are:
        - difficult to type and remember.
        - if someone writes a component to replace your own component
        and want it to be used in the application the original one was used,
        the fact that the code uses the IID directly and not an OAF query
        means that the new component will not be picked up without source code
        hacking.

I know that last time I checked Evolution was using IIDs directly and I cannot
do anything but repeat once more how broken this is: if I write my own
mail component, I am screwed: it will never be displayed unless I hack the code.

Using IIDs destroys the whole point of having components with well defined 
interfaces.

Now, I am trying to figure out how this thread started: if I remmember corectly, 
we were talking about the way IDL interfaces should be named. As far as IDL naming
is concerned, I agree with you on the fact that having a hierarchical naming 
convention is the correct way to go.

However, changing the way OAF uses unique identifiers is:
        1) completely useless since you should not be using those unique identifiers
        in your code.

        2) was already discussed months ago from now and we already decided to keep
        with the current convention.

Nautilus is a demonstration that not using IIDs is possible and is in fact the correct
way to go: it gives a completely dynamic configuration of the application.

Mathieu

-- 
Mathieu Lacage <mathieu eazel com>