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


Hi,
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.

Greetings

eymux

On Wed, Jul 13, 2011 at 12:21 PM, RA Stehmann
<anwalt@rechtsanwalt-stehmann.de> wrote:
Olivier Hallot schrieb:


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

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
that
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 OpenOffice.org branded extensions on a
TDF/LibreOffice service, nor would I be in favor or seeing
TDF/Libreoffice continue to point back to Apache OpenOffice.org 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 OpenOffice.org will have
the same API but a practical common set.

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

Regards
Michael



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

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,
OpenOffice.org 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.

Regards
Michael



--
Unsubscribe instructions: E-mail to discuss+help@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted


-- 
Unsubscribe instructions: E-mail to discuss+help@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

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.