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

if there were an interest in standardizing a macro API for office
applications, I would be much in favor. But I wouldn't want to
standardize the current API. It's unnecessarily complicated and takes
a sizeable amount of time to learn, even for a seasoned programmer.
I'd rather create something new and modern.



On Wed, Jul 13, 2011 at 12:21 PM, RA Stehmann
<> wrote:
Olivier Hallot schrieb:

Em 13-07-2011 05:33, RA Stehmann escreveu:
Uwe Altmann schrieb:

Am 12.07.11 20:38, schrieb drew:
hmmm - that is assuming that the two separate projects will maintain
enough common code base that shared extensions are possible - that is a
requirement that I for one would not want to see enforced. The fact
we can share extensions today is, IMO, a remnant of a past history and
should not dictate decisions for going forward - so I would not be in
favor our hosting Apache branded extensions on a
TDF/LibreOffice service, nor would I be in favor or seeing
TDF/Libreoffice continue to point back to Apache for any
future end user services.
As in past some extensions required some special version of OOo, in
future they may require a special version of LO or only LO or only AOOo
at all. It's more testing but surely can be documented and handeled.
Besides that I dont't expect LO to refurbish the API on a
down-to-the-foundation level in the next years.
There is a solution for that Problem: standardization of the API for
example under the roof of OASIS.

That doesn't necessarily mean, LibreOffice and will have
the same API but a practical common set.

Extensions could notice, whether they use only (parts of) the standard


Isn't this going to put the API into a cast? (for the good and for the bad)

No, it isn't. You can improve standards (like ODF). LibreOffice for
example could develop new API elements especially for new features,
which could be intergrated in a later version of the API standard.

The standard should be only a practical set, supported by LibreOffice, and others. But that doesn't mean the standard describes
the whole API of one of these products but only a great part. So there
is room for improvement.


Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


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.