Difference between revisions of "Extension Deployment"

Revision as of 07:24, 4 April 2006

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.

This is the reason 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.

The OOo registry

OOo comes with its own registry system.

The registry is implemented in a directory named "registry", as well in the shared installation directory as in the user .openoffice.org2/user directory.

When the user modifies its OOo environment, sometimes its registry is changed, sometimes not. The installation process should not alter directly the user OOo directory if this change cause alteration in the registry. In this case, the work should be taken in charge by OOo, thus the installation process should invoque OOo API.

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 something in the pathes, they are 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 (the same from the three files) 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.

Thus, at the installation time, it is pertinent to consider the following cases:

the number and the theme name doesn't exist

to install directly the theme;

the number already exists and the theme name doesn't exist

to search another discriminatory number;

the theme name already exist

to ask the user if the existing theme must be overwritten, or the new one renamed, or its installation aborted.

It is important to systematically search for the theme name in all aready existing themes.

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.

Background

This project should not start out of scratch. Some work has already been done, and here is some non exhaustive reference to it.

• Bernard Marcelly has written a document called "How to Distribute Macros with an Addon" containg macros making very easy to create a package.

• Didier Dorange-Pattoret has written a macro allowing to easily install galleries.

• Philippe Allart has written a simple bash script which comply to the proposed

structure below, and which use the tool of Didier Dorange-Pattoret

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 one directory for each 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/