Marco Fioretti wrote:
As for macros, the issue is more tricky because a macro is a program
>>that tells the application to do something.
Well, not exactly, if I have understood it correctly.
A macro is a small program written in some _language_.
Uhhhm... what does that have to do with anything? Any program is written
in a language.
It is NOT the code _and_ its interpreter. The latter, yes, is definitely not
portable.
????
A macro is a set of instructions to do something. Those use the
application's API. The application is the interpreter.
This is what I'm thinking about:
1) Python interface for opendocument, ie set of function definitions
that read/write odt files and their elements
What you are thinking is a new API. OpenDocument is not an API.
Look, a macro is not like a stand-alone program. It needs to interact
with another program (the application) and must do so through the
application's interfaces (API). It is conceivable that one could make a
standard API for macros, but OpenDocument is not it.
3) Then, you and I write a macro in "Python calling the library
defined in 1) above" on whatever platform and once...
An example of why this is difficult: Now you'd be requiring every
implementation of OpenDocument to include both a copy of Python and a
compliant copy of said library. That's quite a bit to ask.
5) we can then send the .odt file to anybody with:
any .odt program (OO.o, KOffice...) + Python + his own
specific implementation of 1) above...
I'm pretty sure that OpenDocument does not include an API for macros,
much less one that includes Python bindings. I couldn't imagine that
such a thing would be required for OpenDocument compliance.
I have written Python above because it is already useable *today*,
or so I understand, both in OO.o *and* KOffice,
Not through the same APIs and not as part of the OpenDocument standard.
Look, what you want is great, but OpenDocument isn't it.
Any feedback on the flow above, from suggestions on how to implement
it to (polite, please! ) strong criticism is welcome.
Defining a common API between OOo and KOffice would be a challenge.
Getting OASIS to adopt it as part of the file format would be a greater one.
What you want is fantastic, but very very difficult.
Before I forget: if this does make sense, why not add it to the
list of "google summer of code" OO.o projects? Just in case
somebody felt like doing it?
I doubt this could be done in a summer. I doubt that even the spec for
this new API could be agreed on in a summer. But I'm no expert.
Cheers,
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
