Sorry for the delay, I'm on vacations mode.

On Mon, Feb 04, 2013 at 01:44:49PM +0100, Jürgen Schmidt wrote:
> Hi Ariel,
> after some talks about this topic at FOSDEM I was thinking about it
> again. What do you think how much effort it would be to create a new
> scheme for the new extended toolbars and keep the old one at least for a
> while? I know it will be more work in the underlying code but we should
> at least think about it or what do you mean?

I guess you are talking about leaving the "OfficeToolBar" as before:

<set oor:name="OfficeToolBar" oor:node-type="ToolBarItems">

and adding a new set:

<set oor:name="SomeNewNameForExtensionToolbars" oor:node-type="ToolBar">

I don't see the point in having two sets, it's just adding more
complexity and awfulness to the one already there.

And compatibility is not an argument here: an extension that uses this
configuration set is a code-extensions; an extension using simply
toolbar merging might have no code in it, but extensions with own
toolbars have code. Any extension having code, must be checked by the
extension developer in order to adapt it to the incompatible API

For this particular subject of the incompatible change of schema I see
two options:

- leave the change as is

- revert commit in revision 1429069

I'm fine with reverting it; if you think so, simply ask and Ill do it
(side note: you knew it was an incompatible change
http://markmail.org/message/7qbzndiascunlx2i and gave the ok to commit
it - at least Ii had inferred this from seeing my name in
http://markmail.org/message/fhsepy2a56yhubi2 ).

Back to the subject of this thread, that really misses the point mixing
the configuration schema change: the incompatible API changes are not
arguable, this has been already discussed several years ago; it's not
"there is a major version, so let's change the API in an incompatible
way"; on the contrary, it is about API changes that have been on the
queue for a long time, waiting for a major release.

I will only put as example my first code contribution to OpenOffice.org:

It would be interesting that people read the whole thread
http://markmail.org/thread/vdoydqphpsyw2mw6 because the whole thing is
turning now into some kind of dejà-vu.

This is a clear example of an incompatible API change that was known
since the very first time it was developed, and that was waiting since
2008 for a major release; and the incompatible API change was applied in
revision 1425458
http://svn.apache.org/viewvc?view=revision&revision=1425458 and is
tracked under bug 121542

This is a rather illustrative example of me "cleaning up my own mess"
(http://markmail.org/message/m7wousc55loekdxa the whole thread is worth
reading in order to avoid the waste of time of discussing already
discussed things http://markmail.org/thread/tid7fj6mg5wxlz4b), but there
are several other obvious examples; if we had the time and resources
(code contributors), the whole API should be reviewed, going through
every idl file.

And this incompatible API change isn't arguable, that is: it has already
been discussed, I won't revert it, and won't accept anyone else reverting
it, period.

Ariel Constenla-Haile
La Plata, Argentina

Attachment: pgp5SkWv45YV2.pgp
Description: PGP signature

Reply via email to