[api-dev] Re: INFO: New home and EOL of this mailing list in the near future
Hi *, seconding Jürgen's heads-up that this list infrastructure will soon cease existence, let me also point you to LibreOffice and The Document Foundation. When the OOo extension site became more and more unstable, we decided to setup our own extensions and templates repo. LibreOffice and The Document Foundation is a thriving, active community with frequent releases - don't miss out on having your extension tested, developed published there as well! Details here: http://wiki.documentfoundation.org/Extensions_Repository Almost-ready sites: http://extensions-test.libreoffice.org/ http://templates-test.libreoffice.org/ We seek to have developer-related discussions on one list (libreoff...@lists.freedesktop.org), if you're interested in improving the publishing framework, website+subscr...@global.libreoffice.org is where you want to go. We're a new project, low on rules, rich on enthusiasm - and lots of things can still be shaped there. We welcome every contribution. Cheers, -- Thorsten pgpwDoxPZ5W9v.pgp Description: PGP signature
Re: [api-dev] adding a method to a published interface
Hi Malte, you wrote: I think it's better to break AWT API compatibility once, instead of many times in many releases. Which really also might turn out as never - the unlikeliness of the big-bang-change to happen was already pointed out (since when are we talking about awt redesign? I personally think it's 8 years now). If people want to spread API changes over multiple releases, we would need to clarify in advance that API compatibility is nothing we want to take care for anymore in general [...] This is totally misleading. It's highly unlikely that the change Frank is proposing will cause any external incompatibility. Cheers, -- Thorsten signature.asc Description: Digital signature
Re: [api-dev] Thinking about an API deprecation process
Mathias Bauer wrote: Frank Schönheit - Sun Microsystems Germany wrote: I'd say we need a set of highly proficient and highly respected architects, whose opinion should, at least, be weighted high. No, please not! Hi Mathias, FWICT Frank was joking here. ;) Of course (as for every code change) you should do that accountably and talk to other developers that will be influenced by your changes and you should try to make your changes in a way that the potential work of others is minimized. But please no processes, not gate keeper etc. Let things evolve and assume that all participants in the development process act reasonably. A bad API change should be treated as any other code change or patch that we have nowadays: if you see a problem with it, raise your concerns and discuss. Hm. I'm totally with you regarding the dislike of processes. But in contrast to normal code changes, which usually happen on the sole discretion of a single dev, API changes should *require* discussion. Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Stephan Bergmann wrote: On 04/28/09 14:27, Thorsten Behrens wrote: well, Win32 is only one platform, and experience tells that in general, c++ extension *do* break between releases. But you're right, that's not necessarily caused by ABI changes in the strict meaning of the word, a case in point is the 3 layer OOo rework. Hu? http://www.openoffice.org/servlets/ReadMsg?listName=devmsgNo=24706 and http://www.openoffice.org/servlets/ReadMsg?listName=devmsgNo=24718 for example. Maybe I am dumb, but I do not find any mention of broken C++ OOo extensions in those two mails. Hi Stephan, oh, I was under the impression the author is referring to c++ - so then, it's Java? Should we add Java to the list of fragile extension implementations as well? ;) And of course with symbol interposing on elf-based platforms, you get all the fun if someone injects names into the OOo process that are normally bound to e.g. another version of a shipped external lib... I do not see how that would relate to the topic of this thread. Sorry for not being clear - symbol interposing makes it even harder to maintain compatibility for c++ extensions, due to the mutual influence the OOo baseline extensions have on symbol resolution (i.e. a dso already in the lookup scope when an extension is loaded can mess with the extension; conversely, with OOo dlopening uno components using RTLD_GLOBAL, the extension's dependencies can mess with OOo). Although I'd think symbol versioning is supposed to solve this problem, there are apparently enough corner cases (or badly-versioned libs) out there that it fails: http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=23388 (I also remember problems with different versions of the freetype lib, but cannot find any reference currently) Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Mathias Bauer wrote: well, Win32 is only one platform, :-) It's the platform of the overwhelming majority of our users. Hi Mathias, well, the question of *how* overwhelming the majority is, that's indeed interesting (though largely off-topic here, I fear) - what might be the number of desktop Linux users? Estimates range between 15 and 30 millions, and pretty much all of them have OOo installed. What's the current tally of Win32 OOo downloads? As far as I'm concerned, I'm making software for users, not for ends in themselves. So for me there is some sense in trying to keep extensions working as long as the pain for the developers is bearable. We decided that it's about time to take some pain from the developers, but that doesn't mean that we should give up compatibility completely. Granted. And I'm convinced an overwhelming majority of the people here are not doing software for ends in themselves. and experience tells that in general, c++ extension *do* break between releases. No, exactly that is not my experience, not with our careful handling of baselines and backwards compatibility. If am using a very sophisticated Windows C++ extension that was made for OOo 1.x and it is still running well with OOo3. I buy that. But as I said elsewhere, in my book there's a fundamental difference between c++ extensions and e.g. Java- or Python-based ones: it is *much* easier to break compatibility for c++ extensions, and handling them suck when dealing with cross-platform extensions. Given all that, I believe their use should be discouraged, and they should have less weight when it comes to deciding for or against a change that would affect c++ extensions alone. Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Frank Schönheit - Sun Microsystems Germany wrote: [lots of valid points] Hi Frank, no disagreement whatsoever. Who decides? Difficult ... Having a gatekeeper (or multiple fatekeepers) does not really sounds feasible. I would hope that discussing the changes in public until a consensus is reached would work out. Uh, well. While I appreciate striving for consent, this tends to not work so well among hackers - but really no strong feelings here, I'd just suggest to have a tie-breaking rule in case sufficient discussion did not result in a consensus... Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Frank Schönheit - Sun Microsystems Germany wrote: oh, I was under the impression the author is referring to c++ - so then, it's Java? Should we add Java to the list of fragile extension implementations as well? ;) Not sure you're doing the topic a good with this The mentioned mails indeed talked about Java extensions broken by the new bootstrap mechanism (a pretty singular event, hopefully, so please let's not hang this too high). Hi Frank, uh, I did use a ;), right? Anyway, sorry for misunderstanding the post. All known (to me :) C++ extensions use the UDK API only, which I think we should be even more careful with than with the normal office API. If we are, then there's no reason why C++ should not work in different OOo versions ... (well, introducing a dependency to the compiler version or something like this, might be a good idea, but that's independent from API compatibility, IMO.) Compiler versions tend to change, as well as the baseline. And as pointed out, there's other things that can go wrong (especially on non-windows platforms). At any rate, I'd be fine agreeing on the c++ compatibility should have less weight rule you suggested elsewhere - after all, if you need to recompile your c++ extension anyway because a new method or exception has been added to an interface, you're doing that with an updated udk, don't you? Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Mathias Bauer wrote: limit impact considerations to non-ABI-dependent UNO bindings (i.e. the assumption is that c++ components break randomly anyway for every other release, so they shouldn't block API changes) This is not true; in fact on Windows C++ extensions are very stable and at least without a base line change that should be true for other platforms as well (some discipline assumed). Hi Mathias, well, Win32 is only one platform, and experience tells that in general, c++ extension *do* break between releases. But you're right, that's not necessarily caused by ABI changes in the strict meaning of the word, a case in point is the 3 layer OOo rework. My take on that would be: if we allow for incompatible API changes in e.g. a major release, there's no reason not to allow incomatible changes in the C++ libs also. Maybe that's what you wanted to express. No, but that's surely something I can buy into as well. What I wanted to express is that the c++ API/ABI is fragile enough IMO to not hold back with changes that *deliberately* break compatibility there. People should really be encouraged to use (or at least wrap their stuff with) Java or Python when doing extensions; that would also quite nicely solve the problem of (non-)cross-platformness. ;) Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Thinking about an API deprecation process
Stephan Bergmann wrote: On 04/28/09 14:27, Thorsten Behrens wrote: well, Win32 is only one platform, and experience tells that in general, c++ extension *do* break between releases. But you're right, that's not necessarily caused by ABI changes in the strict meaning of the word, a case in point is the 3 layer OOo rework. Hu? http://www.openoffice.org/servlets/ReadMsg?listName=devmsgNo=24706 and http://www.openoffice.org/servlets/ReadMsg?listName=devmsgNo=24718 for example. And of course with symbol interposing on elf-based platforms, you get all the fun if someone injects names into the OOo process that are normally bound to e.g. another version of a shipped external lib... Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] Thinking about an API deprecation process
Hi *, on the last ESC meeting, we had a little brainstorming about if and how to deprecate OOo API. The 'if' was unanimously agreed upon, for the 'how' we came up with the following thoughts: API deprecation === See http://wiki.services.openoffice.org/w/images/2/2a/Esc-mar-2009-api-deprecation.odp for the kickoff slides -- What we need to do -- Decide on preconditions for change: - API was badly designed (architects/pleads to vote if not concordant) Have a list of 'design smells' here, e.g.: * missing exception specifications - API is unused * implemented but unused (can only be easily verified inside OOo code repo, with some more effort inside extension repo - is that enough?) * not implemented (maybe transitively, i.e. listener interfaces, which are meant for API clients, but don't have code to call them inside OOo) - API implementation is too expensive (referring to both effort performance) (architects/pleads to vote if not concordant) What we mean here is e.g. (hypothetical): * profiling xml import has shown that css::xml::sax::XEntityResolver is horribly inefficient and needs a third argument * after the drawing layer rework, one of the css::drawing interfaces needs an inordinate amount of code to emulate old semantics Decide on constraints: - how many clients does this API have * inside OOo code * (estimated) use outside OOo repo * (estimated) number of implementers not reading interface-announce For the latter two, if (at most) recompile is enough, any number of implementers won't block change. For the latter two, if syntactic changes are required, have architects/pleads majority in favor of change? - how 'bad' is the API really – if bad enough, change anyway? Process of Change - when would change be permitted - every feature release, or only major releases? - deprecate API in advance - one or two features releases before the actual removal. Of course, a replacement needs to be available then? - can/should we add technical barriers/support for detecting stale API usage, i.e. refuse to run such extensions? Should we add technical means to warn devs when using deprecated API (either enabled in debug builds, or in a special logging mode of OOo)? Who decides? - we've referred to the entity finally deciding as architects/pleads here; please consider that a place holder. We'd like to hear sensible proposals here also for that committee, also simply voting on the relevant project mailing list is conceivable, or just having the respective project lead decide. Looking forward to your ideas, Kay, Frank Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: Thinking about an API deprecation process
Hey Juergen, *, Juergen Schmidt wrote: Before we start discussing it in more detail, please can we agree to continue on one mailing list only. I would suggest to continue on the dev@api.openoffice.org list because it is API related and the correct list for it. Personally I don't want this limited to _UNO_ API alone, but it might be easier to start with that, so be it. are you aware of this wiki page? http://wiki.services.openoffice.org/wiki/Uno/API_Deprecation no i wasn't and i think it would better fit in the API section because we talk here about a specific handling in the context of OpenOffice.org. But hey we should simply agree on one page ;-) If it's ok for all i would move the content and redirect the uno/API_Deprecation to API/Concepts_API_changes As I said, generally this should apply to _all_ API accessible from third-party code, so no, I would not be too happy with this move. ;) Thanks, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] (Carefully) changing legacy published API?
$subject has been discussed on and off for quite some time - as of now, the law is you must not change published (UNO) API. I'd like to challenge this very rule, since (as all absolute rules) it's silly in practice hinders cleaning up cruft, of which there's abundant in OOo. To spark some heated debate, I've filed a patch issue that adds a whitelist to offapi's type verification - http://www.openoffice.org/issues/show_bug.cgi?id=91943 ;-) Would love to hear your thoughts, and, as Frank proposed somewhere else, we'd probably need some rules of what should be changed (and what not). Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] (Carefully) changing legacy published API?
On Tue, Jul 22, 2008 at 10:46:58AM +0200, Juergen Schmidt wrote: By the way i set your patch to invalid because i think such a whitelist is the wrong mechanism. We already have the possibility to make incompatible changes at the reference rdb but it is not publicly documented and should be done explicitly. We use it for example to correct spelling errors, missing documented properties etc. Hi Jürgen, Issue reopened - then please let's discuss this other solution, preferrably in the issue. Anyway the mechanism should be handled carefully. Don't misunderstand me i am not against API changes in general. I would really love to see some steps in the right direction but not simply by introducing a whitelist without a detailed definition what can be changed. And of course i would keep the current mechanism to explicitly change the reference rdb. Understood - but I'm not happy with mixing this technical question with the general problem of policy (either way, you would surely watch commits to the whatever-it-is mechanism and object changes that violate the to-be-defined policy). I think it is time to relax the incompatiblity statement but with some well defined rules (TBD). It is too important from my point of view and all changes should be well documented and if necessary a migration path should be provided as well. Definitely. I guess there are (at least) the following cases: 1. unused API, or API that crashed OOo, or that was simply ignored when calling the OOo implementation 2. syntactic changes, e.g. renaming, that will only cause recompilation to break, but no existing client (maybe only for a defined subset of frequently used implementation languages) 3. removal/renaming of seldomly used, or long-time deprecated API 4. removal/renaming of often used API I'd say that 1. and 2. could be unanimously agreed upon, 3. needs some careful consideration, e.g. publicly on this list, and a migration path, and 4. should maybe just be left alone. ;-) What do you think? -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
