FAQ on OpenOffice.org API
- From which languages can I use the OpenOffice.org -API?
- What is the difference between UNO IDL and CORBA?
- What's the "size" of the API specification?
- How is the documentation of the API done?
- What is the "size" of the API implementation?
- Do you have any documentation or examples for Java programmers?
- Why are there some interfaces in the OpenOffice.org -API which are not implemented in any OpenOffice.org component?
- How can I find out, if I actually can use a certain interface of the OpenOffice.org -API?
- Are there interfaces to build compound documents like Microsoft's OLE?
- How is conflict resolved on design issues?
- What is your role, Michael Hönnig?
OpenOffice.org implements the API with UNO (Universal Network Objects). Currently there are language bindings for Java and C++. You can implement your own language binding, and in fact we are actively looking for a volunteer to create a C language binding.
Additionally UNO allows control from scripting languages and scripting environments (for example debuggers). Currently StarBASIC (VBA syntax compatible) can call on the API and there is a prototype written for Python integration.
UNO IDL is based on CORBA IDL, but additionally it supports
assigned values for enums,
a new stereotype "service"
(combines interfaces and properties).
And currently it does not support:
|The API consists of about 2000 files, each specifying one type. A type in this respect can be a service, an interface, a struct, an exception, a constant group, or an enum. These files total in about 6 MB of data.
A reference like documentation consists within the IDL files. The syntax of the documentation is based on JavaDoc with a few extensions to mark identifiers. We are currently developing a new generator for this syntax which will generate HTML documents directly from the IDLs.
Our Developers Guide describes the concepts of all components within OpenOffice.org which have an API. It is the best resource to start learning about the API.
Additionally we have a tutorial for StarBASIC programmers. It explains the basic concepts, shows some UML diagrams of the component structure and has plenty of documented examples of the API usage.
|It's hard to impossible to find out. Currently the API implementation is just a wrapper to a core API for the most parts. Only newer components directly implement the API. Thus, there is really not much point in finding out how much code implements the API - and it even makes less sense in the future. Depending on the perspective, we probably can say: The whole OpenOffice.org is an implementation of the API, especially because more and more features are using the API of other components for integration.
|In the UDK project you can find documentation on the language binding for Java. There are some Java examples in the StarOffice SDK which might be helpful for you.
The OpenOffice.org -API is actually more like a specification than an API of a preexisting implementation. Thus there are at several reasons why there are interfaces without any implementation:
|Check for a service which exports this interface, then check for a component which promises to supports this service. Keep optional interfaces in mind (mentioned in the export documentation of the service). If the component you're using still does not implement the interface, it's a bug. In the latter case, please report the bug to the owner of the component. If it's a specification bug, they will forward it to the owner of the specification.
|Within StarOffice API there are no interfaces right now for building compound documents. Our idea is to use the Bonobo model for this purpose.
To begin with, the API is positioned as being a specification which keeps a focus
on an orthogonal structure and reusability. On the other hand we tried to be
as similar to Java as possible. Usability from both sides, the implementation
and the use itself, is another important point. And here often we have to make
compromises - sometimes even because there is a preexisting implementation.
If there are conflicts, we try to find consensus. Just listen to all arguments, give time to find new ones, before hastily make decisions. Try to find a solution everybody is comfortable with.