Extension Deployment

First considerations

Extension deployement should not be considered as an independent task. Indeed, when you need to deploy extensions on a number of workstations, you'll need also to deploy templates, autotexts, gallery themes, and so on, because you'll need to preserve a relative homogeneity. In fact, you'll often need to deploy extensions in the same time you need to deploy templates, autotexts and gallery themes.

That's why it is suggested here to consider the following approach:

1 - to define the structure of a package which aims to deploy in one operation extensions, including macro and toolbars, templates, autotexts and gallery themes;

2 - to define the user interface of an administration tool whose goal is to create such a package;

3 - to define the user interface of a user tool which would enable the end user to install the package on her workstation, or the administrator to install it in the shared installation tree.

Technical context

Before specifying the content of the package, we must keep in mind some technical contraints induced by the implementations of the configuration objects, and the rules for specifying their location.

Default locations

Default locations of the objects seem to be specifyed in the file $(insturl)/share/registry/schema/org/openoffice/Office/Common.xcs

In most configuration files, some frequently used location are referenced via variables:

$(insturl) represents the installation directory, eg. /opt/openoffice.org2.0

$(userurl) represents the user configuration directory, eg. /home/smith/.openoffice.org2/user

$(work) stands for the user work directory.

Templates

The default locations of templates are specifyed in the following XML part:

<prop oor:name="Template" oor:type="oor:string-list">
    <info>
       <desc>Specifies the templates originate from these folders and sub-folders.</desc>
    </info>
    <value oor:separator=":">$(insturl)/share/template/$(vlang):$(userurl)/template</value>
</prop>

Templates are objects very similar of other objects produced with the suite. The only differences stand in the 't' in place of 'd' in the second place of the suffix, and in the virtual tree for accessing to them, built from the set of pathes declared in the configuration files.

From the time the user changes this set of pathes, it is stored in the file $(userurl)/registry/data/org/openoffice/Office/Common.xcu

Autotexts

The default location of autotexts is specifyed in the following XML part:

<prop oor:name="AutoText" oor:type="oor:string-list">
   <info>
       <desc>Contains the directory which contains the AutoText modules.</desc>
   </info>
   <value oor:separator=":">$(insturl)/share/autotext/$(vlang):$(userurl)/autotext</value>
</prop>

Autotexts are organized in categories. The user can create as many categories as her wants, and ask for storing them in one of the directories declared in the configuration file, provided that her has write access. Each category is implemented in a file named <category_name>.bau which is in fact a zip archive.

Nevertheless, if the category name contains special characters, they are silently dropped from the file name. Thus it is more robust to search the category name in the file BlockList.xml included in the archive.

Gallery's themes

At the moment, managment of themes in OOo seems a little bit twisted.

Themes are stored in three binary files, those format are inherited from StarOffice.

This files are suffixed with .sdg, .sdv and .thm.

The .thm file contains, among binary data, the name of the theme, as given by the user.

The name of each file is of the form sgNNN.xxx where NNN is a number and xxx the suffix.

Apparently, the only rule for choosing the number is to obtain unique file names in the target directory.

This implementation is adequat for a local managment of themes, but doesn't give satisfaction when exchanging theme between users. Indeed, the question is: how to detect duplicates during the installation?

using the file name? 

as the file name is, in a way, randomly given during installation, the same theme may be given different names depending on the history of previous installations on different workstations. Furthermore, OOo may have given the same filename to different themes created on different workstations.

using the name stored in the .thm file? 

if this name is too generic, as "people", "events" or "houses", the same name may be given to different themes created by different users.

Macros

to be completed

Toolbars

to be completed

The package manager

At this stage, it is important to consider the package managment provided by OOo V2.

The package manager can import, enable, disable and export packages.

In the package you can store one module containing several libraries of macros.

You can describe additional main menu items, tools menu items and buttons for lauching the macros. The buttons are grouped in one new toolbar.

At the moment, the package manager can't manage templates, autotexts nor gallery themes.

A package is a zip archive.

Specification of a configuration package

To be consistent with the technological choices of the developpers team of OOo, it is suggested that the package be implemented as a zip archive.

This archive should contains a directory by type of object.

Perhaps, it would be a good idea to add a "goodies" directory, allowing to add objects not directly concerned by the configuration process, but which would be very usefull for end users.

Thus, the suggested tree could be as follows:

1. /
   • tools allowing installation of the package
   • specifications for installation (location of templates, ...)
   1. /packages/
      • packages (.zip files) to be installed
   2. /templates/
      • templates to be installed
   3. /autotexts/
      • autotexts (.bau files) to be installed
   4. /gallery/
      • themes to be installed
   5. /goodies/