Re: Continuing discussion of oaf ...

[Ian Campbell <ijc25 cam ac uk>]

Why not simply go for a generally namespaced solution, but reserve a prefix
to represtent "that prefix in which people may use Unique Identifiers)", 

ie people can choose to use:

GNOME::UUID::<some-big-random-number> 

or

GNOME::Desktop::Panel::Applet:1.0:<optional huge number>

obviously the :: are subject to be turned into '_' pr whatever and the
GNOME::UUID:: prefix is likely to cause just as much friction (and so
subject to discusiion/change/argument), I'm not sure if some of the
previous suggestions aren't the same, but it's an idea at least, even if it
isn't new and exciting. I don't even know if I make sense.

I can get my coat if you like,

Ian



On 2000-11-23 01:05:58 +0000 Maciej Stachowiak wrote:
> 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
> 
> 
> _______________________________________________
> gnome-components-list mailing list
> gnome-components-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-components-list
> 



-- 
Ian Campbell
Churchill College, Cambridge.