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

inheritance for exceptions and structures,

assigned values for enums,

a new stereotype "service"
(combines interfaces and properties).

And currently it does not support:

arrays as defined types

unions

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:

1. it could be an optional interface within all services where it is used, but no current implementation actually implements it,
2. it could be an interface to make a concept orthogonal, but the dimension it addresses is not needed right now.
3. it could be part of a recent design which is not implemented yet,
4. its absence in any implementation could simply be a bug.

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.