Hi there!
First of all a big +1 for the proposal from me too.
I would be especially intrested in having something available that could
be used in server applications, eg. from java servlets, to create or
modify ODF documents without the need of having to connect to a running
soffice instance and if possible also without the need of an X server on
Unix systems.
Some comments follow inline....
Kai Sommerfeld wrote:
I wonder if this shouldn't be part of XML or Extensions project?
We thought about this as well and came to the conclusion that an ODF
Toolkit is much more than XML file processing.
It is about defining an
API (therefore, it could belong to the API project) as well as about a
first reference implementation based on existing OOo code.
An ODF API would be a good thing for sure. Reusing existing API´s from
OOo is also a good thing. I could imagine being able to write a
component that works as an extension installed to OpenOffice.org by
using OpenOffice.org API and also standalone installed in an application
server / webserver with the ODF Toolkit API provided that these share a
common base. Reusing existing code is something I am not sure about
wether this is a good approach as it might imply having to use much
things that aren´t really usefull outside the scope of an
Office-application and because it would perhaps imply certain decisions
about the architecture and programming languages used, but well let´s see.
And it is
about attracting developers that have never seen (and do never want to
see) OOo code, but want ODF in their applications. The XML (and all
other) existing OOo code projects require at least some knowledge of OOo
code and architecture in order to understand what's going on there. It
simply is a strange world for those non-OOo developers.
Does this imply that there already IS a decision that the ODF Toolkit
API is not based on UNO (which is one of the biggest thing to learn in
OOo architecture), or is this conclusion wrong?
Personally I would thing a ODF Toolkit could use UNO APIs and enhance
them with some "native"-API´s with stronger language binding which would
be easier to use by providing some more familarity in design to what the
user knows on how things are usually done when programming with his/her
favourite programming language.
The new project makes the connection between OOo and ODF crisp and
clear, but we do not want every user of the toolkit to become an OOo expert.
The toolkit could mainly target developers who want to use ODF on server
side applications. But who knows maybe even competitors of OOo might
want to use that beast in their "Office"-Applications.
- Kai.
Kind regards,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
