Re: Continuing discussion of oaf ...

[Michael Meeks <michael helixcode com>]

Hi Martin,

	[ I hid a proposal at the end of this, if you get bored early on
skip to the end ].

On 22 Nov 2000, Martin Baulig wrote:
> 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.

        Here is a quick summary of the discussion to help:

        Maciej: But there are always more implementations than interfaces
                thus we need mega-uniqueness on the implementation, but  
                not on the interface. Though, if it were possible I'd like
                to use UUID's for interface naming too.
                
        Michael: sadly true currently due to difficulties implementing
                 interfaces, but every component is likely to want to  
                 implement at least 1 new interface [if it is easy to do]
                 Ergo the argument 'we would have to organise the OAFIID 
                 namespace, and this is something new and difficult' is 
                 specious.
                 
> 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.

        My point is, each component needs IDL namespace allocation
already, hence since we already are maintaining a unique namespace for
IDL, we might as well use the same for OAFIDs / oafinfos, instead of some
totaly different scheme.

> Point is:

        ...
           
        Sure; the demerits of using a massive number are only lack of
human readability, and the neccessity to copy chunks of text from a to b,
instead of just reading a plain string + the inability to rapidly verify 
that it contains a typo. cf. GNME_Evolution_Calendar_InstndceFactory

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

        I missed Elliot pointing that out; I saw Mathieu go on about it at
length, and I saw Maciej say that in some cases activation by OAFIID was  
the right thing to do. What I saw from Elliot was the desire not to
mandate anything beyond the 'OAFIID:' prefix, which suits me fine. 

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

        If there is a clash this is because the component is broken and
not following the namespace rules. I don't see this as anymore likely than
some clown cutting and pasting the same oafiid between oafinfo files ( or
more likely copying it and forgetting to change the id ).

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

        But the name is irrelevant to the whole topic. You just change the
name; you will have to change the interface names anyway if you are
producing new, incompatible interfaces otherwise you get serious breakage.
                
> > 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 ?
                 
        Ask Maciej; not my idea. I was suggesting here that Maciej and I 
come from opposite poles of the debate. Maciej would prefer everything to
be massive numbers and I would prefer everything to be human readable and
following the same namespace. Both poles are logical and consistant, I
just postulate that mine is better, and neither is currently  
implemented. However, mine has the merit of being implementable now.

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

        We are discussing a namespace; the filenames are clearly a
namespace, consequently they should be treated with the same regard for
non-conflict as anything else. The logical extent of Maciej's argument is
that these should be huge random numbers [ which is at least more logical
than 'just some name I made up' which is what we currently have ].   

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

        So you suggest namespacing the oaf/ directory into
sub-directories, I couldn't agree more, controversial though :-)  

> >         OAFIID: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".

        This is not an interface, ( since you seem to be a fan of using
underscores ) I change my example to:

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

        It's not an interface, neither does it appear in the list of
supported interfaces, neither does it have an 'IDL:' prefix or a '1.0'  
suffix. The intention is simply to re-use the existing, neccessary IDL
namespace for naming components.

> 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

        And this will cause no real problems; indeed, I reccommend this
naming scheme ( in combination with the UUID ) for things like panel
applets that are very noddy and are never likely to implement any new
interfaces, eg.

        OAFIID:GNOME_Vertigo_AppletFactory:213-345-324-2-34-23-234-324

        So;

        Again I re-state my case:

        * We already have a need for an allocated namespace, the IDL
namespace.

        * We have 2 other currently badly managed namespaces to whit
oafinfo filenames and OAFIIDs.

        * These need fixing; it is not acceptable to leave it as it is.  

        * I propose we use the same namespace for both of these to
garentee a conflict free experience.

        * Since Maciej seems to dislike having sub-directories; I suggest
we use the '_' to delimit them in the filenames [ this means banning the
use of '_' in the more general namespace ] hence we get (eg.)

        /flat_space/oaf/GNOME_Vertigo.oafinfo
        /flat_space/oaf/GNOME_Evolution_Calendar.oafinfo
        /flat_space/oaf/GNOME_Nautilus_HardwareView.oafinfo

        etc.

        I further propose that we homogenise naming of OAFIID's to conform
to:

        OAFIID:GNOME_Vertigo_InstanceFactory:[optional IID]
        OAFIID:GNOME_Evolution_Calendar_InstanceFactory:[optional IID]
        OAFIID:GNOME_Nautilus_HardwareView_InstanceFactory:[optional IID]

        For people that want to use the IID and are deeply concerned about
the insufficient uniqueness of the above proposal, the option to add an
unfeasibly large number at the end is open.

        This scheme would seem to fit well with what we have at the moment
and can be implemented across various components fairly simply.

        Comments ? flames ? set the GEGL on me ? or shall I get to it and
start going round the place knobbling oafinfo files ?

        Regards,
 
                Michael.

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