Re: Continuing discussion of oaf ...

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

Michael Meeks <michael helixcode com> writes:

>         I state this because there are some that say we need a greater
> level of uniqueness amongst implementations than interfaces. Clearly I
> agree with this for some cases ( eg. panel applets ), where the UUID is
> most appropriate. However, I think this is a fringe case.

I tend to disagree here again.

What you are suggesting is doing a technically wrong thing just to get a
very little bit more convenience.

By suggesting that we can leave away the UUID when activating an object,
I was actually making a big compromise - of course it is technically wrong
and broken to activate by the short form (without the UUID).

I only suggested this to make it a bit more convenient for you guys who
absolutely want to activate by OAFIID and are too lazy to do it the right
way and with the hope that we can strongly, strongly deprecate this usage.

However, I just realized how broken this is and how confused I was.

>         I look forward to this prediction coming true. eg. examine the
> number of Open Office interfaces; I count: 1972 idls ( ok so some fraction
> of these will be service contracts ), but lets say that 1/2 are services
> so we have 1000 interfaces; lets say we split Open office into OCalc,
> OWriter, OBase... say 10 separate implementations; this is 100 interfaces
> per component approximately.

Haha, good joke :-)

Do you really thing "we" (ie. the "Core GNOME" + Open Office + the big GNOME
companies) will ever get such clashes ?

Surely we will not.

We can clearly namespace our stuff, fix things, etc.


                                  * * *

But GNOME is not only Open Office and big companies who're able to clearly
namespace their stuff, we'll also get a lot of hobbyist users of our libraries
who just hack together some IRC client in their spare time.

When you look at Windows, there are both the big programs and a very, very,
very large number to shareware-like, user contributed stuff like games.

I expect that the same will happen with GNOME when we're becoming successful,
we will get a large number of small programs - and their authors don't know
about each other nor do they want to do all this bureaucratic stuff of
registering a namespace for their stuff, they just call their programs like
they want.

I think most of these programs won't provide any IDLs of their own, they'll
merely implement the existing ones (leads to my "more implementations than
interfaces" theory).

By using UUIDs we can avoid a lot of trouble here:

a) First of all, it solves all problems when there's a clash between two or
   more such programs - when you activate by full OAFIID, it'll still do the
   right thing.

   Also, I still think that clashes in IDL files won't cause any problems
   here since they'll be in different .idl files and you'll normally only
   include/use one of them, but not both.

b) Clashes between such a program and a core GNOME component.

   Even this can be solved with UUIDs - when you install such a program,
   your GNOME system will still continue to work.

   However, there is a problem with a clash in IDL files - this will almost
   always cause problems with scripting languages.

Another problem with such shareware-like programs is that they tend to get
old and un-maintained so that you cannot assume that you'll be able to fix
problems as they arise - when such a program pollutes the GNOME namespace,
then we're screwed without UUIDs.

Again, I don't see clashes in IDL files being such a big problem, not even
for scripting languages (you should get an error when you try to load that
IDL file, but you should still be able to use the core GNOME interfaces
without problems if you don't include/use the clashing IDL).

However, without UUIDs we'll be in big trouble when we get a clash.

It's easy to explain users that if they install a broken component they
cannot use that component because it's broken.

It's hard to explain our users that after installing a broken component their
whole core GNOME system will be screwed and that they must uninstall that
component first.

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