• The zipped JavaDoc API
  
• The JAR of the reference Java 5 implementation
  
• The zipped NetBeans package containing the sources of ODFDOM v0.6.

tags: api architecture code development netbeans odf opendocument software specification sun xml

ODFDOM is the name of the upcoming free OpenDocument framework sponsored by Sun Microsystems Inc.

It will be the next evolutionary step after AODL and Odf4j. Designed together with their architects with the intent to provide an easy lightwork programming API for the ODF developer community. ODFDOM is meant to be portable to any object-oriented language.

The first pre-version of the Java 5 reference implementation of ODFDOM is planned to become available under LGPL3 in May 2008.

Please find further detailed information in the OOo Wiki.

 

tags: api architecture code development netbeans odf opendocument software specification sun xml

I recently stumbled over a broader Gnome vision regarding an Online Desktop (see here), which sounds reasonable new and ambitious.

I just would like to take the opportunity to present my very own little ideas regarding OOo, in no particular order.

• All OOo is going to be MVC (Model View Controller).
• There are no different applications any more, but just work approaches, representing the former Calc, Writer etc., internally they are using the same data structures (Models, Views, Controllers), e.g. the same tables in Calc as in Writer as in Impress etc.
• The API allows objects to be combined in a linear independent way, e.g. creating a paragraph to be added to various tables, documents, sheets, presentation etc.
• The architecture is strictly event-driven, including I/O. No polling, hanging etc. any more because of slow or failing I/O.
• Everybody is using the new Uno threading-model, avoiding hand crafted thread related programming mostly everywhere.
• The GUI is described in a purely declarative language, e.g. as XUL.
• The build system uses (GNU) make only, relies on dependencies solely and gives useful progress information ("compiling <module>/source/<foo.cxx>" etc.) only, not cluttering the console anymore.
• We have unit tests for (nearly) everything, so that changes can be verified in concise scenarios.
• There is in fact no difference between a document and an extension, both can be opened temporarily (file->open) but also be deployed permanently (tools->Extension Manager).
• OOo would be available as classic installation sets (.rpm, .deb, msi, ...), suitable for the apt/sources.lst, as Java Web Start Technology etc.
• There is a marketplace where open source developers as well as commercial entities can offer their services.

Many visions etc. are in the heads (fingers?) of the community, and may not (yet) be written down explicitly. I am pretty sure that, if asking, most people can give a list of what's coming and what they are currently thinking about.

tags: architecture openoffice.org vision

This is a part of my latest posting to my blog.

Initially I only wanted to write about the latest security issues. In the end it was more about architecture and I better should have posted it here.

So this is the point: Why do we ship 3rd party libraries with OOo?!

There are 3 reasons for shipping these libraries with SO/OOo, instead of making them a system requirement:

1) It's convenient for the user. Just download and install the productivity suite, don't care about additional downloads and installations.

2) Modified versions. In some cases SO/OOo ship modified versions of 3rd party libraries, because we made some bug fixes which are not available in the official versions from that library right now.

3) No problems with ABI compatibility. Sometimes 3rd party libraries change in a way that they become incompatible with current versions of SO/OOo. Sometimes even in a way that the users doesn't recognize it immediately (application still starts), but some things behave differently (and wrong). This happens for example when introducing new enum values in the middle of existing values. An example for this can be found in the FreeType library, which was responsible for one of the security vulnerabilities.

But in general, there should only be one copy of each library on a system, if possible. Programs shouldn't install "private copies".

Funny. I was just searching for some public documentation about our ARC Process, because ARC also checks for private copies, when stumbling over a very recent OpenSolaris blog from a colleague.

Item #5 is exactly what we are talking about here...

tags: arc architecture openoffice.org opensolaris security solaris staroffice