Future advances in hardware performance will come from parallel execution rather than faster execution. However, in order to benefit from these advances, application code will need to change. Then, in what ways will OOo have to change so that it will count as a productive 21st century office suite? What languages will we be writing code in tomorrow, and what paradigms will we use? Will UNO turn out a strategic advantage in moving forward, or will it become a burden? Is the UNO threading framework a step in the right direction? Where shall we start? And what has the Wizard of Oz got to do with it?

OpenOffice.org is not as monolithic as it might appear sometimes. Its internal architecture allows to work in one module without the necessity to change others. Some modules that build the framework and architecture of OpenOffice.org have an influence on the other modules and working on any higher level module as e.g. the Writer module is not possibly without understanding the basic modules and how they interact with the others.

This presentation will outline the general software architecture of OpenOffice.org to enable interested developers to find their way into the code. It will also give hints to further documentation.

Startup time of OOo is not insignificant – everyone knows that. But there are other large applications that look like starting instantly; what do they do differently? Are they cheating? Or not?

This talk will describe the cheating techniques used by others, and also the ones that we do already (early feedback – startup notification, splash, etc.; re-using a running instance; preloading an instance; ...)

Where the cheating ends, we will talk about improvements and optimizations made by Novell, including some that did not find their way to the up-stream OOo yet.

We looked at several factors that could help improve OpenOffice.org startup performance, especially on Linux. We focused on disk sub-system-level solutions to mitigate performance impact of several application-specific factors. At launch, especially on cold-start, the application makes significant scattered disk accesses, due to a combination of page-faults arising out of execution flow and dynamic library loads interspersed with configuration reads and writes. We will therefore focus on speedup techniques based on reducing the disk access penalty at startup.

A systemic approach of minimizing seek penalties is to arrange data blocks used during application start-up in an appropriate sequence on the disk. We will briefly describe our trace gathering and simulation environment for costing and optimizing block order for a collection of application disk access traces. We will also discuss results and experiences for a prototype reordering scheme for the ext2 filesystem. We will outline the design and progress on a post-install reordering utility for OpenOffice.org, and conclude by presenting some initial ideas on extending and generalizing this approach into an adaptive monitoring and optimizing mechanism with kernel and file-system support.

The second approach is a deep refactoring of configmgr using berkeleydb to, in effect, coalesce configuration data into a contiguous disk block. A new backend, dbbe, accesses xml blobs stored in the database, avoiding multiple file reads. We will discuss our experiences creating a new backend as well as further opportunities for optimizing configmgr.

More or less frequently people complain about OOo in respect to multi threading. Either because it is complicated to implement a service, or that there is only few documentation, or that the UNO API is not thread safe, or that it does not scale etc.

The “Cleaning Up OOo Multi Threading” effort1 aims to put OOos usage of multiple threads on a solid base, while simplifying the implementation of thread related OOo respectively UNO code, eliminating anachronistic constructs such as the Solar Mutex or the Main Thread Executor.

This sessions gives a brief overview over OOos current usage of threads and how synchronization primitives are used to protect office code and data. It develops a solution of how to simplify thread related code development and where OOo should head wrt its threading architecture2. It gives a brief overview of the UNO based implementation of the suggested solution, how it works and how it has been applied to OOo.

Openoffice.org offers a lot of scripting capabilities. A complete framework and API is available to adapt and drive the office elements to your wokflow and daily activities. The available languages to access this API are numerous and one can start easily to develop extensions and macros with OOoBasic and Python languages.

The session will present the different tools like the IDE, SDK and other available helpers. Then some starting elements covering the first steps of extensions(macros) creation in OOoBasic will be presented. Addon and Extensions creation using Python will also be covered, showing the power and simplicity of the pyUNO approach.

OpenOffice.org is a large monolithic build, and has a large output install image size. One problem of this is for distributions which want to ship bugfix updates to their users and customers. For most distributions the smallest addressable update unit is effectively that of src.rpm. All output rpms which are generated from a given src.rpm are included in the update set.

Other similiarly large monolithic build trees have been split into separately buildable modules e.g. x.org. This enables separate src.rpms to be created, and independant update builds of the afflicted src.rpms with consequently faster builds for updates, and smaller update sizes. Here I outline a sample modular-build split of OpenOffice.org into OpenOffice.org-URE and the rest of OpenOffice.org.

The target of the BOF is that by discussing the problem and a prototype sample solution an understanding might be reached as to the viability to a universally acceptable modular build process.

A How-to presentation on the prototype Jam build system and how it can reduce those convenient “go fetch coffee and take a break” moments of compilation. After this session you should know how to use the prototype, why to use it, and a bit about what's inside. Also inluded by popular demand: “Top Ten common usage patterns that will cause the prototype to promptly explode and disintegrate your planet”

We will detail a new system being developed for openoffice.org, that will allow automated testing of  code changes and make life easier for QA. This system, using build-bot, allows developers to submit their CWS or SVN branch for building, testing, and install-set creation on different architectures and configurations. By including performance, code-quality, and correctness tests in the battery, we allow developers to track regressions across many platforms, without requiring those platforms in their possession. By making install sets available from the build, we enable developers to submit their changes easily, even when they don't have the same platforms/build systems as QA.

In addition, the automated nature of the system makes running these tests easy and painless. The “head” branch can also be automatically tested, giving a running regression for the project as a whole. With this system, we hope to make the process of making changes and getting them integrated considerably less difficult for developers and QA engineers alike.

The session will give an overview of the OpenOffice.org extension infrastructure.

The OpenOffice.org office suite gets more and more popular and the demand to customize or extend the existing functionality by own extensions is growing as well to integrate it in existing business workflows. Customized extensions can provide new functionality or can be the interface to other applications, e.g. integration in document management systems.

But what are the requirements for the extensions infrastructure to provide a reliable framework for deploying and maintaining extensions for several versions of OpenOffice.org? Even that is important for ISV's to protect their intellectual property and to make it possible to run a business based on extensions and an open source product.

This session will try to cover this question. Requirements like licensing, versioning, dependencies and others are discussed and the session will give an overview of the current status and what is planned for the near future. Besides the common requirements a special focus will be taken on   commercial extensions.

Getting introduced to UNO programming and URE use is not an easy task. This session is about to explain how to create a new URE application without to much pain. An occasion to show the state of the Eclipse integration project, this session will demonstrate the features of the plugin and expose its possible future.

Large-scale C++ development is tough business, and so is grokking and improving OOo's  approximately 6 million lines of code. The author will share the accumulated knowledge of Sun's OOo development team, touching areas such as:

• dependency management: how to architect for encapsulation
• tools for working on the code: IDE/editor review, (semi)-automatic code transformations and refactorings, debuggers
• patterns: the most frequent design patterns and their incarnations
• helpers: the what and the where of helper functionality
• recommended readings: literature, links to OOo resources (API documentation, coding guidelines), mailing lists and news groups

This session should be suitable for all levels of C++ programmers, that want to become familiar with OOo's way of doing things in C++.