FAQ on OpenOffice API

From which languages can I use the OpenOffice-API?

OpenOffice 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.

What is the difference between UNO IDL and CORBA IDL?

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

What is the "size" of the API specification?

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.

How is the documentation of the API done?

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.

Additionally we have a "programmers manual" which explains the basic concepts, shows some UML diagrams of the component structure and has plenty of documented examples of the API usage. This manual currently uses StarBASIC as a language for the examples, but we are working on a Java version as well.

What is the "size" of the API implementation?

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 directy 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 is an implementation of the API, especially because more and more features are using the API of other components for integration.

Do you have any documentation or examples for Java programmers?

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.

Why are there some interfaces in the OpenOffice-API which are not implemented in any OpenOffice component?

The OpenOffice-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.

How can I find out if I can use a certain interface of the OpenOffice-API?

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.

Are there interfaces to build compound documents like Microsofts OLE?

Within StarOffice API there are no interfaces right now for building compound documents. Our idea is to use the Bonobo model for this purpose.

How is conflict resolved on design issues?

To begin with, the API is positioned as being a specification which keeps a focus on an orthogonal structure and reuseablity. 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.

What is your role, Michael Hönnig?

I have been the chief architect of the StarOffice API, which now becomes the OpenOffice API. My primary responsibility was to ensure a common path, make guidelines for IDLs and take care for that they are followed, find generalizable interfaces, build a common API infrastructure, and take care for the documentation.

I am willing to continue this job as long as my person is supported by the community.