Re: a small summary.

[Michael Hoennig "(mi)" <mi sun com>]

Hi Mathieu,

Michael Meeks already gave a great answer to your "small summary". But to 
bring the whole discussion back to the core, I'd like to add some hints - 
moving away from this stupid naming convention things.

To begin with, as Michael Meeks already stated, we are not talking about 
supporting BONOBO in OpenOffice just to integrate OpenOffice with GNOME. 
We are actually speaking about merging the APIs to build the application 
specific OpenOffice APIs on top of them. This means, we are speaking 
about the possibility of building OpenOffice on top of BONOBO instead of 
just supporting it by a wrapper. And for sure you can see which momentum 
this would give to GNOME and BONOBO.

Actually, I think this is not even enough. We have to get Mozilla into 
this boat as well. Of cause we know, that will not make the whole process 
easier. But, on the other hand, if WE don't do that now, all future UNIX 
developers will have to suffer from it. And I can easily understand why 
people are attracted by the Windows platform just for the reason of 
having a single API instead of half a dozen. One thing is an unchangeable 
fact: the LATER we do this merger, the LESS possible it is at all.

No to the naming conventions: I personally do not care about studly caps 
or underscores. Neither do I personally care about an "X" prefix for 
interfaces. Although the latter only, if there is a solution for the file 
name conflicts on reference documentation generation. Such a discussion 
is just a waste of time - normally.

But here we don't have a normal situation. The StarOffice API - which now 
is the OpenOffice API - is already released for quite a time. And many 
external programs are build on top of it - mostly legacy applications for 
very special purposes like governmental administration. On the other 
hand, BONOBO is not released yet to externals. The other argument is the 
amount of APIs which exist: here too the handicap is on the side of 
OpenOffice. If we change, we have to change much more than GNOME would 
have to.

That still does not mean, we were not willing to change anything at all. 
But I think, if we take half of BONOBOs interfaces, dropping our 
counterparts, and exchange half the BONOBO interfaces by interfaces from 
the OpenOffice API, OpenOffice still would have to change more than 
BONOBO does. Of cause, the merger will not be so easy (50:50) - in some 
cases we will merge interfaces, taking ideas from both sides.

BTW: I am convinced, it is pretty easy to change namespaces, a medium 
thing to change interface-names and a tough thing to change method names. 
So much for a comment (from Maciej I thing), if we changed the scope, it 
does not matter if we changed everything.

And now to the core problem, which I mentioned before, but nobody gave 
even a single comment on it. If OpenOffice went for BONOBO, every change 
to BONOBO would directly affect OpenOffice - and probably again 
externals. If the BONOBO community does not care about such things, we 
simply cannot rely on BONOBO. This would mean, we had to keep our APIs 
separate - and the UNIX community has to continue to suffer from so many 
APIs (having in mind that it would only be a small step anyway - but at 
least a step in the right direction).

> The main purpose of this post is to point out my growing frustration
> because of this obvious unwillingness to compromise. 

Do you still think, we are not willing for a compromise? I think, even if 
we took our whole naming conventions and API designs into BONOBO, it 
still would be a big compromise from OpenOffice's side - just because 
OpenOffice would lose control about extremely central important APIs. If 
these APIs will get changed again after OpenOffice is out for a year or 
so, we would be up-shit-creek!

Speaking about 400 OpenOffice developers (there are not so many): It 
really does no matter if all they put their vote in here or not. The 
decision is to be made, whether OpenOffice API merges with BONOBO or not. 
"Not" still means, we were implementing a wrapper to integrate with 
BONOBO - but a wapper is never as good as a native integration. And 
future developers still had to deal with two APIs.

If I get the feeling, the GNOME/BONOBO community is supporting my vision, 
I will continue to go for it and argue for it. If not, the APIs will 
remain separate. Though that would be a pity!

	Michael