Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On 03/06/2013 04:47 PM, Andre Fischer wrote:
On 06.03.2013 15:25, Stephan Bergmann wrote:
On 03/06/2013 09:00 AM, Andre Fischer wrote:
On 05.03.2013 18:29, Michael Meeks wrote:
On Tue, 2013-03-05 at 09:19 -0800, Fred Ollinger wrote:
I was wondering if libreoffice and aooo can't agree to
some basic level api for 3rd party developers?
    It's an interesting discussion; but in the absence of any concrete
code, patches etc. it doesn't belong on the libreoffice developer list;

Talking about a concrete change is a good idea so please let me ask a
question similar to one I asked at FOSDEM but to which I got no clear
answer.  Probably because of my bad English that is even worse when I
speak it.

Stephan Bergman talked about "Well-typed UNO", something that would
involve incompatible changes to the UNO API.  I would like to know if
LibreOffice and Apache OpenOffice could work together on this. I am
just talking about changes on API level not the underlying
implementation.  That would be something that both projects would do
independently.

First off, depends on what you mean with "UNO API."  One customary
meaning is the set of UNOIDL entities (mainly) declared in udkapi/ and
offapi/ .idl files.  (LibreOffice tries to meticulously track any
incompatible changes it does there, see e.g., the "API Changes"
section at
<http://www.libreoffice.org/download/4-0-new-features-and-fixes/>.)

Another customary meaning is the broader concept of stable interface
the URE offers, including C ABI, file formats, wire protocols, etc. My
hope is that my work on changing the type representation does not
affect the former, only the latter (file formats etc.).  And,
obviously, it will need to take care of a backward-compatibility plan.

By "UNO API" I mean everything that affects a packaged extension, that
is basically your option B.  So if I understand you correctly that an
extension developer just has to recompile (for a C++ extension) the
source code, repackage the extension and is done (with respect to your
changes).  That sounds good.

It should basically boil down to: If you include a types.rdb in your extension, you can translate it to the new format (or not, in which case your extension will work as long as we keep the backwards-compatibility code alive). If you don't include something like that (and that's likely most extensions anyway, except for Calc Add-Ons), you don't need to do anything at all.

That said, I can only repeat now what I already said at FOSDEM, that
I'm going to well document all the changes to any
specifications---just like I did for any other changes to UNO I did
over the last ten years or so.  And, as always, any input is highly
welcome.

Great. Thanks.
Do you have a pointer to the relevant documentation?

Not yet. As always, things progress more slowly than I'd hoped. Stay tuned, though. ;)

Stephan

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.