Re: Oaf names & file structure - ?

[Michael Meeks <michael helixcode com>]

Hi Mathieu,

On 18 Nov 2000, Mathieu Lacage wrote:
> 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:
 
        I'm sorry to hear life sucks. From what I understand Maciej merely
re-iterated my assertions that the namespace should be owned by the
foundation in my first mail; what about that did you fail to get ?     

> the foundation should own the namespace and its allocation.
  
        Amen; what do you not understand in my above paragraph "I agree
the foundation should own the namespaces" ? My comment on rubber stamping,
is that of Miguel's, ie. we do not need a committe to decide the most
trivial of things, who should use what namespace. Although appealing to 
the board is clearly open to anyone who feels we are doing a bad job of
helping people decide what namespace to use. I know of no-one who feels   
that way currently, do you ?

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

        Hmm; I was never convinced. I think various people argued fairly
feebly, and we came to a stalemate not a consensus. I'd like to re-open
the debate where we left off.
  
> 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.

        I disagree; applications hardcode the OAFIID into their sourcecode
and also their oafinfo files. I have written all the debugging code in oaf
in this area to try and help people who screw up cut and pasting their
huge IID's since this happened to me several times. I think a plain
textual name has many merits and no real demerits.

> 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.
        
        Dude; this is not the case, and has not been for a very long time
now. Please see evolution/shell/e-shell.c (setup_components):

        info_list = oaf_query ("repo_ids.has
                ('IDL:GNOME/Evolution/ShellComponent:1.0')", NULL, &ev);

        etc.

>         1) completely useless since you should not be using those
> unique identifiers in your code.

        As previously noted you use these identifiers in your code
already; see eg. nautilus/src/nautilus-application.c.

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

        You made have made this decision, I think it is the wrong one, I
am sorry if the discussion tires you, please ignore it. 
 
> 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.

        Well; I am most curious about this per application selection of
default components. Can we not build in a tool to tweak oaf to have a
default order of query results per application ? either way; while I agree
that capability based application is a nice thing in every respect, I
think demanding a specific ( standard ) component can in some
circumstances be the right thing to do. Eg.

        you can determine that an application supports the Control
interface, but not that it's property bag supports a certain property; or
again, that it supports the NautilusServiceWhatever interface, but perhaps
not that an object returned from a method in that interface implements a
certain service. [ but then the component may not be able to tell this
itself until run-time ]. In these cases, where there is a tighter contract
than can be specified in oaf between the components, or possibly for QA
reasons, where it is not desirable to have 5th party components linking 
against your binary, I think OAFIID activation can be useful.

        Either way; this is a rather peripheral issue, to my thesis which
is one of having nice, human readable, easily verifiable names everywhere,
which has to be a good thing IMHO.

        Regards,

                Michael.

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