Quoting Bernd Eilers <[EMAIL PROTECTED]>:
Hi there!
[...]
please let me know what you think of my reply to Daniel, where I
talk of a set of python functions etc....
What I think is that you think about things that in reality are very
hughe and complex as being small and simple things. When you say "A set
of python functions" that just sounds like you are thinking an API for
an Office Programm like OOo would only need well let´s say only a
handful of functions to be exposed to someone wanting to write macros or
extensions in Python or whatever language. The reality is much
different: OOo exposes lots of special tiny details to the programmer
enabeling a wide range of possibilities to modify documents and the user
interface or to automate tasks.
The OOo API can be called from different languages Basic, java, pyhton,
C++, ...
Please have a look at the reference manual at
http://api.openoffice.org/docs/common/ref/com/sun/star/module-ix.html
to see how big and complex the API really is.
This is definitifly not something that can be redesigned and rewritten
from scratch easily in a few man-weeks work (eg. it´s not doable in some
summer code camp or something similar like you suggested). One would
have to do it all again from scratch if a new API should be created
which should be usable by more than one open source applications.
Despite that the implementation of the API is interlocked with the
implementation of the programs features, which means you would have to
rewrite most if not all of that too. The Koffice API might eventually be
not that complex but you can be sure it´s totally different. And thus it
would not be easy to align those two.
If those two office packages had almost zero history and - well lets say
development would just have been started a few weeks ago on them or
similar - things may be different, but after all why start two fresh
projects than using the same API, you would be better of concentrating
on finishing one using the API you would have designed.
Having said all that I suppose if it´s just for the very very very
simple tasks like inserting some text into a document etc. there might
in theory be the possibility to create two versions of a small library,
exposing the same API to the programmer using two different sets of the
underlying more complex Application APIs insided. Portability would than
be there but usability and options for such a lib would be very limited
compared to using the applications current own APIs directly.
Thanks,
Marco
Kind regards,
Bernd
I think marco's point is something similar to for example Python relationship
with Mysql, there are two libraries, MySQLdb-python and mysql-python which are
wrappers sometimes overlapping each other.
What Marco want is a set of pre-configured instructions that will ease the
development of text manipulation, element recognition, etc. This wont necesary
re-design or re-implement the API it will just simplify the basic level of
manipulation through wrappers.
Small example would be to get rid of the com.sun.star which are
repeated through
out all the components/modules of the scripting ( I think some languages
already do).
--
Alexandro Colorado
Co-Leader of OpenOffice.org Spanish
http://es.openoffice.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
