Re: Continuing discussion of oaf ...

[Martin Baulig <martin home-of-linux org>]

Michael Meeks <michael helixcode com> writes:

> On 20 Nov 2000, Maciej Stachowiak wrote:
> > > UUID's are a short term hack, that relies on the assumption that
> > > most people will not want to implement any new interfaces, which is
> > > just silly. True, currently it is too difficult to do so, but I
> > > expect this to become easier through a several pronged strategy.
> >
> > I don't see what implementing new interfaces has to do with it?
> 
>         If every component implements a new interface then every component
> already needs to deal with the namespacing issues. Consequently for every
> application that implements a new interface the UUID is just a pain in the
> butt. Your thesis that _Implementation_ ID's are in any way different to
> interface ID's is based on the ( currently accurate ) sad premis that new
> components will typicaly not implement any new interfaces.

Hi Michael,

I don't really understand what you mean with this - the more components we
get the more imporant it is to keep the UUID to make sure they're really
unique.

> > I don't think being easy to type is a requirement; #defines should be   
> > used anyway to avoid typos, the bane of magic string constants.
> 
>         No one is arguing with this; however you still have to copy the
> massive string from the oafinfo file to the C source file. I do not find
> the argument of 'compile #define files from the oafinfo files' argument
> over-convincing. This will create more autoconf hassle, needing manual
> rule insertion all over the place, and it is not clear what to call the
> #define.

Point is:

1.) To copy this sting from the oafinfo file to the C source file, you
    normally open the oafinfo file in your favourite editor, mark that
    string, then open your C source file and insert that string. This
    is even easier than typing the sort version (without the UUID) by
    hand and for cut&paste it makes no difference at all how long the
    string is.

2.) You do this _once_ when you create your C source file and you don't
    need to do it ever again.

So for this scenario there's no reason at all to leave off the UIID part.

However, in some very rare situations you may want to activate a specific
component and thus use the hardcoded OAFIID in your app (as Elliot already
pointed out this is a very bad thing).

a.) With the current setup (UUID part required), you still open the oafinfo
    file, copy&paste it into a #define and - done.

b.) Without the UUID requirement, the best thing to do is still to use a
    #define to avoid that you mistype it, so there's not really a difference.

Now assume we leave the UUID part away or make it optional.

This makes it a very little bit easier for us right now - but imagine, what
happens if in 3 years, when we are having a lot of different components, there
actually _is_ a clash where two components end up having the same ID.

Ooops, we're in big trouble ... how do you want to fix this ?

Other point:

At the moment, this is not really an issue, but what will happen after GNOME 2,
after GNOME 2 of maybe even earlier, we may run into the situation that there
are two incompatible versions of the same component - this could easily be
handled with the same name, but a different UUID ...

>         Anyway; the arguments all essentialy boil down to the fact that we
> both want a homogeneous naming convention, you seem to prefer:     
> 
>         OAFINFO::Massive random number - IID

Not really, more

        OAFINFO:GNOME_eog_image_viewer:Massive random number - IID

>         IDL:Massive random number:1.0  - interface name ( if possible )
> and thus logicaly: ( speculation here )

Why do you want to use random numbers in IDL names, this makes no sense at
all to me ?

        IDL:GNOME/EOG/ImageViewer:1.0

>         /prefix/share/oaf/Massive random number.oafinfo

I think it's not necessarily required to have a random number in the filename,
this is just a packaging issue where you only make sure that your file doesn't
clash with anything else.

So

        /prefix/share/oaf/GNOME/eog-image-viewer.oafinfo

would seem fine to me.

>         OAFINFO:GNOME/Gnumeric/InstanceFactory - IID

Eeek, that's actually a must not.

Naming the IID after the IDL name effectively means "you must not attempt
to write any component which implements this interface or you'll end up in
very big trouble".

You may argue that nobody is supposed to ever implement this interface
since it's Gnumeric internal, but I tend to disagree here:

a) as soon as an IDL file is installed, it is per definition not "private"

b) newcomers tend to use the way we do stuff as an example on how to do stuff,
   this means that if you use `OAFINFO:GNOME/Gnumeric/InstanceFactory' - there
   will be the day where someone writes

        IDL:GNOME/IRC/GenerallyUsefulInterface/SuperChat:1.0

   and puts

        OAFINFO:GNOME/IRC/GenerallyUserfulInterface/SuperChat

   into his .oafinfo file.
   Ooops :-(

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)