Re: Continuing discussion of oaf ...

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael helixcode com> writes:

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

I think you are simply wrong about this. I think there will be a lot
of useful components that don't implement any interfaces besides the
standard Bonobo ones.

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

Elliot said it was to be avoided. I agree but think it is sometimes
necessary (although rarely).

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

It's a lot easier for two developers working completely independently
to accidentally pick the same human-readable string name than to
accidentally pick the same UUID; the latter is more or less impossible
short of doing it intentionally.


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

I wish you would stop completely misrepresenting my views. How many
times do I have to correct you before you will stop? I don't think
consistency in naming of interfaces, implementations and files is a
requirement at all.


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

I disagree. There are two main reasons filenames are different than
implementation ID strings.

1) A conflict in filenames can be detected at install time, since the
   filesystem already enforces pathname uniqueness. A conflict in IIDs
   may not be detected until much later when the system mysteriously
   malfunctions.

2) It's possible for a packager or installer to rename a file or
   install it in a different prefix to resolve conflicts without
   adversely affecting anything. However, changing an IID in a package
   will break all external code that depends on the IID. Thus,
   filename conflicts can be resolved at the packaging/install phase,
   but IID conflicts cannot.

For these two reasons, IIDs must have much stricter uniqueness
requirements than filenames.

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

Whereas I'd suggest "OAFIID:GNOME_Vertigo_clock-applet-factory:uu-id-blah-blah-blah",
"OAFIID:GNOME_Vertigo_desk-guide-applet-factory:uu-id-blah-blah-blah",
etc, so the human readable parts can be distinguished in a dump of IIDs.


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

Your case is wrong, interface names, implementation names and
filenames all have different requirements and different externally
imposed constraints. Overlooking these differences leads to bad design
through oversimplification.

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

I'm fine with this naming scheme. I will recommend it. I'm also going
to recommend changing the suffix to just .oaf as soon as I implement
support for that.

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

I am happy to recommend this as well, however, I'm not going to
declare the UUID portion optional. It will remain a non-optional part
of the recommendation. Again, I do nothing to enforce IID conformance
to the recommendation, although I'd hope all core GNOME apps would
conform.

You posting the same arguments over and over is not going to change
anyone's mind. I realize you dislike the UUIDs but we can't all have
things exactly the way we want.

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

Please let's get a written recommendation into oaf/doc first, and
then gradually change files to conform to the recommendation.

The main remaining open issue to me is: what naming scheme do you use
for the oafinfo file names and for IIDs if you have no IDL namespace
allocation because you have no custom IDL interfaces? I'm just not
going to buy the argument that everyone will have at least one custom
interface.

Once we address that, I will write up a new naming recommendation and
post it here.

 - Maciej