Re: Namespacing issues ...

[Michael Meeks <michael helixcode com>]

Hi Martin
        
On 17 Nov 2000, Martin Baulig wrote:

>     First of all, I think we need to "control" the GNOME/ and Bonobo/
> namespaces a bit. I mean, we should have some kind of registration  
> authority for it.

        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.
        
> This means that we'll have some database or something which maps all
> names in the 2nd-level GNOME/ namespace to the
> application/project/author.

        Luckily this is not a big problem at the moment; I have a vauge
review of the various apps and their namespaces here; I'll commit it to  
Bonobo shortly; a flat text file should suffice I think.
        
>     This should make sure we don't get any clashes within the GNOME/
> namespace when we start getting a lot of third-party applications.
                                
        I imagine most 3rd party applications to use eg.
  
        com/borland/kylix/IDE/GUIDevel

        etc. following the standard OMG rules.

> 2.) The OAFIID and .oafinfo issue
>
>     Currently we have "OAFIID:eog_image_viewer:..." - I think we should
also
>     change all of them to something like
"OAFIID:GNOME:EOG_image_viewer" so
>     that all OAFIID's contain `GNOME:' and the application name `EOG_'.
        
        Yes; I have discussed this with Miguel. I think there is little
point in these massive OAFIID's; in fact I totaly hate them. We are agreed
that a better naming scheme here is (eg.)
                

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'.
                                        
>     Same applies for the file/directory names of the .oafinfo files.

        I agree. When I put this position some time ago; Maciej complained
that we would have to poll these directories for new IDL files and that
this would be a performance hit in oafd.
          
        I think that is a feeble argument; I think we should have a
structured share/oaf tree following the IDL namespaces eg.

       share/
                oaf/
                        GNOME/
                                Evolution/
                                        shell.oafinfo
                                        addressbook.oafinfo
                                        calendar.oafinfo
                                        wombat.oafinfo
                                Nautilus/
                                        shell.oafinfo
                                        directory-view.oafinfo
                                        iconlist.oafinfo
                                Gnome-db/
                                        libgda.oafinfo
                                        db.oafinfo
                                gnumeric.oafinfo
                                guppi3.oafinfo
                                eog.oafinfo
                        org/ 
                                mozilla/
                                        shell.oafinfo
                                        avi-render.oafinfo
                        com/
                                sun/
                                        star/
                                                writer.oafinfo
                                                calc.oafinfo
        
                                inprise/
                                        kylix-designer.oafinfo
                                        kylix-editor.oafinfo
                                        delphi/
                                                debugger.oafinfo
                                kompany/
                                        failed_product.oafinfo
                                ibm/
                                        dragon-dictate/
                                                process.oafinfo
                                                speech-text.oafinfo
                                ms/
                                        office/
                                                word.oafinfo
                
        etc. etc.
                                
> I'll do this with Eog this afternoon.

        Thanks.                         

> > As if this mail was not controversial enough; might I suggest that
> > if you are running such a script over your IDL, that it might be a
> > good time to migrate to the new API naming convention as outlined in
> > bonobo/doc/FAQ.
>         
> I don't want to start another flameware here, but this looks like you
> now want to get studlyCapsification everywhere in GNOME through the
> backdoor ..... ?
       
        I don't want studlycapsification 'everywhere in GNOME' I want the
same naming convention to be used across all of our _Idl_. I dislike
stdlycaps in normal C method names [ as previously discussed ad nauseum ],
but consistancy across the component model is important. This was just
pointing out that if you are doing a load of IDL related perl scripting
anyway; now might be a good time =)
                                        
        I assume this is why Maciej agreed to change the oaf IDL if Bonobo
went ahead with the change; whatever our personaly feelings about the
change, consistancy is good.

        Regards,
                                
                Michael.

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