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

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