[tdf-discuss] macro compatibility between LO and AOO?

[Stephan Bergmann]

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