Hi, 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"> </set> and adding a new set: <set oor:name="SomeNewNameForExtensionToolbars" oor:node-type="ToolBar"> </set> 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 changes. For this particular subject of the incompatible change of schema I see two options: - leave the change as is - revert commit in revision 1429069 http://svn.apache.org/viewvc?view=revision&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: http://markmail.org/message/ntqgiwaclcuhuzfk 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 https://issues.apache.org/ooo/show_bug.cgi?id=121542#c2 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. Regards -- Ariel Constenla-Haile La Plata, Argentina
pgp5SkWv45YV2.pgp
Description: PGP signature
