Oaf names & file structure

[Michael Meeks <michael helixcode com>]

Hi Maciej,

On 17 Nov 2000, Maciej Stachowiak wrote:
> Michael Meeks <michael helixcode com> writes:
> > I don't think this is a massive problem; I propse that Miguel and 
> > I resolve such issues as and when they arise ( which is unlikely ) and
> > if people get unhappy they can appeal to the foundation who will
> > probably 'own' the space in some more formal way.
>
> I think the GNOME namespace should definitely be owned and controlled
> by the Foundation (which should delegate pieces of it to app authors
> on request). Probably it should delegate the task to some subcommittee
> to take care of this. I will raise this with the Board.

        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.

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

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

> You could achieve the same thing solely with filenames. We don't split
> /usr/bin into a complex multi-level directory tree and I see no
> argument for doing it here.

        I am happy to do the work if that concerns you. As for /usr/bin
not being namespaced; this is why we need the PATH variable, so StarOffice
can be installed in /opt/Office, X in /usr/X11R6/bin etc. etc. and I would
prefer not to have this.

        Companies will not be happy putting stuff in a global namespace  
that anyone could screw them with. They will [ as you demand ] use a
different prefix / path. Then they _somehow_ have to fiddle the
OAF_INFO_PATH environment variable for all their users, so oaf can actualy
see the stuff [ oh, and they also have to re-start oafd, which is not easy
to do in a portable way ].

        And this is your preferred solution to having a single directory,
that is cleanly namespaced into sub directories, where companies and
projects can put whatever they wish ?

        NB. the only problem with this that you can imagine is a
performance problem polling lots of directores. This problem is so feeble,
that I begin to suspect there must be some better reason for your dislike
of a more sensible naming space that you are not giving, I'd love to hear
it. Of course, again, I am happy to put the work and testing in to ensure
that oafd does this properly.

> >         I think that is a feeble argument; I think we should have a
> > structured share/oaf tree following the IDL namespaces eg.
>
> Following the IDL namespace is broken unless there is one and only one
> component that implements any given IDL interface.

        I've lost you here ? do you not agree then that application
specific interfaces ( which I assume we agree will exist ), should be  
implemented using the standard OMG namespacing conventions which will put 
them in a hierarchical, structured system that could ( and should ) be
mirrored in the oafinfo directory structure ?

        Either way; it doesn't much matter whether a component implements
any custom interfaces, a sane namespacing scheme for oafinfo files is
important. And I don't buy the minimal changes: "it's so elegant to name
the file:"

        org-netscape-mozilla-rendering_core.oafinfo

        this blows.

> but I will try to do it to OAF before GNOME 1.4. I haven't had time to
> do it myself yet, but I'll take a patch.
        
        I'll knock one up for you next week.

> However, we can't do any IDL renames for stable released modules until  
> GNOME 2.0 (something I pointed out on the original renaming thread).   

        Ok; perhaps, it depends how much of a bug you see this as being; I
tend to think it is quite a large bug, but I'm not very concerned about 
the relatively minor cockups in the released modules.
 
        Regards,

                Michael.

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