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 <[email protected]> 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 [email protected] > 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 [email protected] 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
