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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Fernand Vanrie
On 4/03/2013 8:27, M. Fioretti wrote:
> On Mon, Mar 04, 2013 08:16:25 AM +0100, Fernand Vanrie wrote:
>
>> 99% percent , changes comes and will come from incompatiliteis in de API.
>> for now this is OK, small changes from version to version, but
>> nothing who not can been repaired or handled with the code( basic)
>> itself
> I knew that. The sense of my question is, is there is a list of things
> to avoid beforehand, rather than wait that they break and fix the
> code?
thats more a question for the developers list .
[hidden email]  and fore the aOO counterpart
[hidden email]
>
> Thanks,
> Marco
>

Reply | Threaded
Open this post in threaded view
|

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

Keith Curtis
On Mon, Mar 4, 2013 at 1:46 AM, Fernand Vanrie <[hidden email]> wrote:

> On 4/03/2013 8:27, M. Fioretti wrote:
>>
>> On Mon, Mar 04, 2013 08:16:25 AM +0100, Fernand Vanrie wrote:
>>
>>> 99% percent , changes comes and will come from incompatiliteis in de API.
>>> for now this is OK, small changes from version to version, but
>>> nothing who not can been repaired or handled with the code( basic)
>>> itself
>>
>> I knew that. The sense of my question is, is there is a list of things
>> to avoid beforehand, rather than wait that they break and fix the
>> code?
>
> thats more a question for the developers list .
> [hidden email]  and fore the aOO counterpart
> [hidden email]
>
>>
>> Thanks,
>> Marco

The reason why nobody responded is no one knows, and it will generally
get worse over time as the codebases diverge. It is sort of like the
Java: "write once, test everywhere" situation.

One of the unintended consequences of the fork is the various ways it
makes things more difficult for third-parties. Users will generally
pick one product, but extension developers have a more complicated set
of choices because they may want to support multiple brands. Here is
an article I recently wrote about the power of brands that may be
helpful: http://keithcu.com/wordpress/?p=3163

The good news is that in the free software world, code flows with less
friction. Any typical (non-enterprise) who really wants an extension
will likely be able to install a specific version of the product if it
is required. It is just a download.

Good luck!

Regards,

-Keith

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Fred Ollinger
I know that there were reasons for the fork and I respect that. I was
wondering if libreoffice and aooo can't agree to some basic level api
for 3rd party developers?

Probably not, but I think it's worth asking.

Fred

On Tue, Mar 5, 2013 at 8:28 AM, Keith Curtis <[hidden email]> wrote:

> On Mon, Mar 4, 2013 at 1:46 AM, Fernand Vanrie <[hidden email]> wrote:
>> On 4/03/2013 8:27, M. Fioretti wrote:
>>>
>>> On Mon, Mar 04, 2013 08:16:25 AM +0100, Fernand Vanrie wrote:
>>>
>>>> 99% percent , changes comes and will come from incompatiliteis in de API.
>>>> for now this is OK, small changes from version to version, but
>>>> nothing who not can been repaired or handled with the code( basic)
>>>> itself
>>>
>>> I knew that. The sense of my question is, is there is a list of things
>>> to avoid beforehand, rather than wait that they break and fix the
>>> code?
>>
>> thats more a question for the developers list .
>> [hidden email]  and fore the aOO counterpart
>> [hidden email]
>>
>>>
>>> Thanks,
>>> Marco
>
> The reason why nobody responded is no one knows, and it will generally
> get worse over time as the codebases diverge. It is sort of like the
> Java: "write once, test everywhere" situation.
>
> One of the unintended consequences of the fork is the various ways it
> makes things more difficult for third-parties. Users will generally
> pick one product, but extension developers have a more complicated set
> of choices because they may want to support multiple brands. Here is
> an article I recently wrote about the power of brands that may be
> helpful: http://keithcu.com/wordpress/?p=3163
>
> The good news is that in the free software world, code flows with less
> friction. Any typical (non-enterprise) who really wants an extension
> will likely be able to install a specific version of the product if it
> is required. It is just a download.
>
> Good luck!
>
> Regards,
>
> -Keith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Michael Meeks-3
Hi guys,

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;
please drop that one from the CC.

        Thanks,

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Andre Fischer
On 05.03.2013 18:29, Michael Meeks wrote:
> Hi guys,
>
> 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.

I am asking this because I think that the users of both LO and AOO
would benefit from APIs that are as similar as possible.  I am aware
that there are other incompatible changes in both projects but every
part of the API that remains compatible between LO and AOO means that an
extension developer does not have to care about it when developing an
extension for both projects.

> please drop that one from the CC.

As my question is directed at (to?) the LibreOffice developers, I hope
that you don't mind that I have put the LO list back on CC.

Thanks,
     Andre

>
> Thanks,
>
> Michael.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Stephan Bergmann
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.

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.

Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Andre Fischer
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.

>
> 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?

-Andre

>
> Stephan


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]