5  Extensions

An extension is a file intended for the distribution of code and / or data which is to be used by OOo. The file has the file extension “oxt”(formerly .uno.pkg and .zip), and it acts as a container for various items, such as libraries, JARs, configuration data, type libraries, Basic libraries, Basic dialogs, etc.  Before OOo can use any content of the extension, it needs to be installed by the Extension Manager.

The Extension Manager is a tool for managing extensions and other deployable items, such as separate libraries, JARs, configuration data files. This includes adding, removing, enabling and disabling of these items. 

The Extension Manager can be started from within the office  by pressing the menu item Tools | Extension Manager or by running the unopkg executable, which is contained in the program directory of the office installation.

When an extension is installed, then a copy is created which is kept either in the user installation or the shared installation (<office-directory>/share).  The original extension can therefore be (re) moved after installation.

The Extension Manager can be used to deploy various types of files. It is primarily used for extensions. The latest incarnation of an extensions is the .oxt file, which has superseded “.uno.pkg” and “.zip”. 

Apart from extensions the Extension Manager can also manage these types: 

• Configuration data (.xcu, .xcs) 

• UNO Libraries (.dll /.so).  

• JARs (.jar) 

• Type libraries (.rdb) 

When installing an extension one has to decide if all possible users can use it or only oneself. In the first case,  users cannot enable, disable or remove the extension. This can only be done by the administrator. That also means, that in case the extension changes the appearance (toolbars, menu bar, etc.), all users are affected. They may, however, configure their office so that particular menu or toolbar items are not shown. There is currently no way to centrally install an extension for particular user groups.

If an extension is to be installed for all users or only for the single user is determined during installation. The person, who is going to install the extension, must select in the Extension Manager dialog either “My Extensions” or “OpenOffice.org Extensions” before pressing the “Add...” button.  In the first case, the extension will only be installed for the current user, whereas in the latter case it  will be installed for all users.

When running unopkg in a windowless mode then the option “--shared” determines if an extension can be used by all users. For example: 

[<OfficePath>/program] $ unopkg add --shared my_extension.oxt 

would install my_extensions, so that it can be used by all users. 

Extensions which are installed for all users are also called shared extensions, and those installed only for the user (who installed it) are called user extensions.  

Within a running office the Extension Manager is started through the menu item “Tools | Extension Manager ...”.  When started in this way,  extensions can only be installed as user extensions.  All items deployed under “OpenOffice.org Extensions cannot be modified. But it is possible to export them.

The unopkg executable offers another way to start the Extension Manager.  It supersedes the pkgchk executable which was used in OpenOffice.org 1.1.0 and older versions and which no longer works.

In contrast to the Extension Manager in OpenOffice.org unopkg can also  manage  shared extensions. For example:

[<OfficePath>/program] $ unopkg add --shared my_extension.oxt 

installs my_extension.oxt for all users. 

unopkg offers a windowless mode in which all interactions occurs through the console. This is the default. If unopkg is started with the subcommand “gui” then the Extension Manager dialog appears which is exactly the same as the one in OpenOffice.org. 

[<OfficePath>/program] $ unopkg gui 

The difference is that in the dialog all items deployed under “OpenOffice.org Extensions” can be modified and new items can be added there as well. All actions, that is, adding, removing, etc. can be done in the dialog. Therefore “unopkg gui” does not require any more parameters. 

It follows a short overview what can be done with unopkg. Since there are many more commands, have a look at the help text that can be obtained by calling “unopkg -h”.

First of all open a console and change into the program directory of the office installation. 

Adding an extension for a single user: 

[<OfficePath>/program] $ unopkg add my_extension.oxt 

Adding an extension for all users: 

[<OfficePath>/program] $ unopkg add --shared my_extension.oxt 

An extension is a zip file having a name that ends on “.oxt“ (formerly ”.uno.pkg” or “.zip”).  The file extension .oxt is associated with the MIME / media type vnd.openofficeorg.extension.  An extension can contain UNO components, type libraries, configuration files, dialog or basic libraries, etc.

Extensions now have unique identifiers. This removes the previous restriction that no two extensions with identical file names can be deployed. 

Technically, an extension identifier is a finite sequence of Unicode scalar values. Identifier identity is element-by-element identity of the sequences (no case folding, no normalization, etc.). It is assumed that extension writers cooperate to keep extension identifiers unique. By convention, use lowercase reversed-domain-name syntax (e.g., “org.openoffice.”) prefixes to generate unique (but still humanly comprehensible) identifiers. When you write an extension, use the reversed domain name of a site you controll (and not “org.openoffice.”) as prefix. Identifiers starting with the prefix “org.openoffice.legacy.” are reserved for legacy extensions (see next).

The extension identifier is obtained from the description.xml contained in the extension. If the extension does not specify such an explicit identifier, then an implict identifier is generated by prepending “org.openoffice.legacy.” to the (obvious sequence of Unicode scalar values representing the) file name of the extension. (Uniqueness of identifiers is then guaranteed by the assumption underlying legacy extension management that no two legacy extensions have the same file name.)

Extensions are often improved over time. That is, publishers want to ship new versions of the same extension with added functionality and/or bug fixes. Adding extension versions allows publishers to ship new versions, and allows [PRODCUTNAME] to detect and handle the case that an extension installed by the user is an update of an existing extension. 

Technically, an extension version v is defined as an infinite sequence of non-negative integers v = ‹v0, v1, ...› where all but a finite number of elements have the value zero. A total order is defined on versions via lexicographical comparison. A textual representation of a version v = ‹v0, v1, ...› is a finite string built from the BNF

version ::= [element (“.” element)*]

element ::= (“0” | “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9”)+

of n ≥ 0 elements where each element is a decimal representation of vi for 0 ≤ i < n, and each vi = 0 for i ≥ n.

The extension version is obtained from the description.xml contained in the extension. If the extension does not specify such an explicit version, then an implict textual version representation of the empty string (representing a version of all zeroes) is assumed. 

No general semantics are prescribed to versions, other than the total order which determines whether one version is less than, equal to, or greater than another version, respectively. However, extension publishers are encouraged to use the widely accepted three-level scheme of major (incompatible changes), minor (compatible changes), micro (bug fixes) where applicable. 

The description.xml is a means to provide additional useful information, such as dependencies, license and update information. It will be extended to support new features in the future. The file must be located in the root of the extension and the name is case sensitive. 

The description.xml is searched case sensitive in an oxt package. This is important to know when you package your extensions content into a new oxt package.

XPath: /description 

Parent element:  document root

Child elements: 

XPath: /description/registration  

XPath: /description/dependencies 

XPath: /description/update-information 

XPath: /description/registration/simple-license 

XPath: /description/dependencies/OpenOffice.org-minimal-version 

XPath: /description/update-information/src 

XPath: /description/registration/simple-license/license-text 

<?xml version="1.0" encoding="UTF-8"?>

<description xmlns="http://openoffice.org/extensions/description/2006" xmlns:d="http://openoffice.org/extensions/description/2006" 

    xmlns:xlink="http://www.w3.org/1999/xlink">

    <version value="1.0" />    

    <dependencies>

         <OpenOffice.org-minimal-version value="2.2" d:name="OpenOffice.org 2.2"/>

    </dependencies>

    <update-information>

      <src xlink:href="http://extensions.openoffice.org/testarea/desktop/license/update/lic3.update.xml" />

    </update-information>

    <registration>

        <simple-license  accept-by="admin" default-license-id="en-NZ" suppress-on-update="true" >

            <license-text xlink:href="registration/license_de-DE.txt" lang="de-DE" />

            <license-text xlink:href="registration/license_en-GB.txt" lang="en-GB" />

            <license-text xlink:href="registration/license_en-NZ.txt" lang="en-NZ" license-id="en-NZ" />

            <license-text xlink:href="registration/license_en-US.txt" lang="en-US" />

        </simple-license>

    </registration>

</description> 

This description.xml contains these information: 

• The version is 1.0. 

• It only works with OpenOffice.org 2.2 and better. 

• It supports the update feature and update information can be obtained at the specified address.

• When this extension is installed as shared extension then a license text is being displayed. Different localizations of the license text are available. 

This feature is about displaying a license text to the user during installation. The user can agree or decline the license, where in the latter case the installation will be aborted.  It is called “Simple License” because there is no tamper resistant mechanism that prevents the installation in case the user does not agree to the license. It also does not do anything more than just displaying a license text. However it provides a way to use localized licenses. More on that later.

The license text is displayed either in a dialog or in the console dependent on the way the package manager was started. When it was started by the tools->Package Manager menu item or by invoking unopkg gui in the console then a dialog is used. By using unopkg add the license text will be displayed in the console and user input has to be done through the same.

The license dialog or the license text in the console is displayed when the extension is being installed. Currently there are two modes to install extensions, user mode and shared mode. An extension that was installed in user mode (let's call it a user extension) can only be used by just that person who installed it. If the extension was installed in shared mode (let's call it a shared extension), then it can be used by all users.  Since the license text is only displayed during installation, all users who are using a shared extension will not see any license text (except the user who installed this shared extension). However, the publisher of the extension may think it necessary that everyone who wants to use it has to agree to the license first. For this purpose, he can mark the extension accordingly. This extension can then only be installed in user mode and not in shared mode. Likewise the extension can be marked indicating that only the person who installs it needs to agree to the license. Such an extension can be installed in both modes.  But when installing in user mode then every user has to agree to the license nonetheless.

Here is an example of the description.xml: 

<?xml version="1.0" encoding="UTF-8"?>

<description xmlns="http://openoffice.org/extensions/description/2006"

    xmlns:xlink="http://www.w3.org/1999/xlink">

    <registration>

        <simple-license  accept-by="user" default-license-id="de">

            <license-text xlink:href="registration/license_de.txt" lang="de" license-id="de" />

            <license-text xlink:href="registration/license_en_US.txt" lang="en-US" />

        </simple-license>

    </registration>

</description>

In this example, the license would have to be agreed to by all users (that means no shared mode installation). This is indicated by the value “user” of the attribute accept-by in the <simple-license> element. The attribute could also have the value “admin”, which would indicate that the license needs only be agreed to by the person who installs it.

The <license-text> elements contain information about the files which contain the text that is displayed. The content of these files must be UTF-8 encoded. It is displayed exactly as it is in the file. That is, no formatting occurs. There can be one to many <license-text> elements, where each element provides information about a different language of the license text. The attribute xlink:href contains a relative URL (relative to the root directory of the extension) which points to a file which countains the license text in exacty one language. Which language is indicated by lang attribute.

If the package manager does not find a <license-text> element which matches the locale of OOo then it will pick the <license-text> that is marked as the default language. This mark is expressed by the license-id attribute of <license-text> and the default-license-id attribute of the <simple-license> element. There must always be exactly one <license-text> whose attribute value is the same as that from <simple-license>. This <license-text> element is then used as the default.

The locale used by OOo and the license text files is expressed by a language string according to RFC 3066. This string contains the language and can optionally contain a country and further information.  Let's assume that the office uses britisch english (en-GB) end the extension has two license text files, one in german (de), which is also the default, and the other in english from New Zealand (en-NZ). Obviously there is no perfekt match, since en-GB is not en-NZ. But we would not want to use the default yet, because en-NZ is most probably closer to en-GB as german. Therefore we use an algorithm that tries to find a “close match” of the local before it resorts to the default. Here is the algorithm:

In order to find the appropriate <license-text> element, the values of lang attribute are compared with the office's Locale. Both are represented as strings according to RFC3066. The comparison is done case sensitive.

Input to the algorithm: 

• All license-text elements.

• The locale of the office 

Output of the algoritm: 

• A license-text element

Algorithm: 

1. The language, country and variant part of the office's locale are used to find a matching license-text.  If there is an exact match then the respective license-text is selected as output and we are done. Only the first match is used.

2. The language and country part of the office's locale are used to find a matching license-text. If there is an exact match then the respective license-text is selected as output and we are done.

3. The language and country part of the office's locale are used to find a matching license-text. This time, we try to match only the language and country parts. For example, the office locale strings “en-US”, “en-US-east” match the lang attribute with the values “en-US-north”, “en-US-south”,etc. The first license-text with a matching lang attribute is selected as output. If there is a match then we are done.

4. Only the language part of the office's locale is used to find a matching license-text. If there is an exact match then the respective license-text is selected as output and we are done. Only the first match is used.

5. Only the language part of the office's locale is used to find a matching license-text. This time, we try to match only the language part. For example, the office locale strings “en”, “en-US”, “en-US-east” match the lang attribute with the values “en-GB”,“en-GB-north”, etc. The first license-text with a matching lang attributed is selected as output. If there is a match then we are done.

6. The license-text element which is marked as “default” will be selected. That is, the value of the attribute license-id must match the default-license-id of the simple-license element.

The following example show what values would match. 

Example 1: Locale of OOo is en-US and the relevant part of the description.xml is:

<simple-license accept-by="user" default-license-id="en-US" > 

  <license-text xlink:href="lic_en-GB" lang="en-GB"  />

  <license-text xlink:href="lic_en-US" lang="en-US" license-id="en-US" />

</simple-license> 

The <license-text> with lang=”en-US” will be selected. 

Example 2: Locale of OOo is en-US and the relevant part of the description.xml is:

<simple-license accept-by="user" default-license-id="en-NZ" > 

  <license-text xlink:href="lic_en-GB" lang="en-GB"  />

  <license-text xlink:href="lic_en-NZ" lang="en-NZ" license-id="en-NZ" />

</simple-license> 

The <license-text> with lang=”en-GB” will be selected. 

Example 3: Locale of OOo is en-US and the relevant part of the description.xml is:

<simple-license accept-by="user" default-license-id="en-NZ" > 

  <license-text xlink:href="lic_en" lang="en" />

  <license-text xlink:href="lic_en-GB" lang="en-GB"  />

  <license-text xlink:href="lic_en-NZ" lang="en-NZ" license-id="en-NZ" />

</simple-license> 

The <license-text> with lang=”en” will be selected. 

Example 4: Locale of OOo is de-DE and the relevant part of the description.xml is:

<simple-license accept-by="user" default-license-id="en-NZ" >

  <license-text xlink:href="lic_en" lang="en" />

  <license-text xlink:href="lic_en-GB" lang="en-GB"  />

  <license-text xlink:href="lic_en-NZ" lang="en-NZ" license-id="en-NZ" />

</simple-license> 

The <license-text> with lang=”en-NZ” will be selected. 

One can imagine a large variety of dependencies an extension can have on its environment: availability of certain UNO types and services, availability of features only present since some specific version of OOo, availability of other installed extensions, availability of third-party libraries, etc. 

To support this, a mechanism is introduced so that extensions can bring along a specification of their dependencies. When a user wants to install an extension, the application first checks whether all dependencies are met.  If not, an error dialog is displayed informing the user that the extension could not be installed.

The only actual dependency currently defined is <OpenOffice.org-minimal-version value=“X”>, where X is the required underlying OpenOffice.org version (“2.1”, “2.2”, etc.), starting with OpenOffice.org 2.1. (Even if an extension is installed in a derived product like StarOffice, this dependency is on the underlying OpenOffice.org version.)

OOo 2.0.3 and earlier are not prepared to correctly handle extensions with dependencies. In OOo 2.0.3 and earlier, if a .uno.pkg (or .zip) extension specifies any dependencies, they are effectively ignored and the extension is installed nonetheless. An .oxt extension cannot be installed at all in OOo 2.0.3 and earlier. So, if an extension shall run in any OOo version, it should be named .uno.pkg and should not specify any dependencies; if an extension shall only run in OOo 2.0.4 and later, it should be named .oxt and should not specify any dependencies; and if an extension shall only run in a future OOo version, it should be named .oxt and should specify the appropriate dependencies (which will be defined by the time the given OOo version is available).

There is a certain dilemma: On the one hand, nothing is yet known about the kinds of dependencies that will be defined in the future. On the other hand, at least some information about the unsatisfied dependencies of a future extension must be displayed in OOo 2.0.4. Therefore, each dependency specified by an extension must contain a human-readable (non-localized, English) name that can be displayed to the user, conveying at least rudimentary information about the nature of the unsatisfied dependency. Future versions of OOo that already know a certain kind of dependency are expected to display more detailed information.

Likewise, when new dependencies are defined over time, old versions of OOo will not know about them. Those old OOo will thus reject extensions making use of those dependencies, even if the old OOo version would actually satisfy the dependencies. Therefore, each dependency specified by an extension may optionally contain an OpenOffice.org-minimal-version attribute that specifies the minimal version of OOo that would satisfy the dependency. Old versions of OOo that do not know the given dependency will then check for the optional attribute and, if present, nevertheless accept the dependency if the given version is large enough. This feature is only supported since OOo 2.3.

Within the description.xml, dependencies are recorded as follows: An XML element whose name consists of the namespace name http://openoffice.org/extensions/description/2006 and the local part dependencies may appear at most once as a child of the root element. This element has as its element content an arbitrary number of child elements that are not further constrained expect for the following: Each such child element should have an attribute whose name consists of the namespace  name http://openoffice.org/extensions/description/2006 and the local part name, and it may optionally have an attribute whose name consists of the namespace http://openoffice.org/extensions/description/2006 and the local part OpenOffice.org-minimal-version. Each such child element represents one dependency, and the value of its name attribute shall contain the human-readable dependency name (and the value, after normalization, should not be empty).

If an extensions is either not of type .oxt, .uno.pkg, or .zip, or does not contain a description.xml, or the description.xml does not contain a dependencies element, or the dependencies element does not contain any child elements, then the extension does not specify any dependencies.

When installing OpenOffice.org, the installation routine  is adding information to the system which can be used by other software products to install extensions.  For example, double-clicking on an extension in a file browser should start the Extension Manager and install the extension. Also mail clients and web browser should offer a way of installing the extension, when it comes as an attachment of an e-mail or is the target of a link.

Extension which are installed by way of using the system integration are always installed as user extensions.

The system integration is available since OOo 2.2.  

Extensions are often improved over a period of time. That is, publishers ship new versions of the same extension with added functionality and/or bug fixes. Currently users must update their extensions manually, that is, find out where to get updates, obtain the updates, remove the old extensions, install the new extension. This feature will make updating easier. Users can run the update mechanism from the Extension Manager. A dialog will show available updates and the user will be able to choose which to install.  

More particular information for this feature can be found in the specification at: 

The update procedure needs to be started by the user in the Extension Manager. One can update all installed extensions by pressing the “Updates” button or select particular extensions, press the right mouse button and select “Update” in the context menu. The extension manager will then try to obtain update information for the affected extension. If it finds that a new version of an extension is available then it will be displayed in the update window.

In some cases an update cannot be installed, for example because the  installed extension is shared by all users and the current user does not have permission to manage shared extensions. In this case a message to this regard is displayed in the window.  To update shared extensions one needs to close OpenOffice.org and run unopkg gui. Then the user has access to all extensions.

An extension may also not be installable, because it has unfulfilled dependencies. For example,  the extensions requires a particular version of OpenOffice.org.

The user can determine which of the updates he wants to install by checking them. When the “Download and Installation” button is pressed then, as the name suggests, the extensions are being downloaded and installed. 

The actual download location of an update is contained in the update information which is typically a xml file which is hosted on a server.  Every update information contains only information for exactly one extension.  The most important information are the location of the update and the version of this extension.

By using  an atom feed one has greater flexibility in terms of where the actual updates are hosted. For example, a company which has published many extensions, may utilize just one atom feed which are referenced by all extensions. The location of this atom feed must be well chosen, because changing it may break the automatic update. Then the Extension Manager cannot obtain update information for these extensions anymore.  For this reason, the company could set up a dedicated server which is guaranteed to be available  in the foreseeable future. The actual extensions can then be hosted on different servers. The atom feed file needs only be edited if an update information file is moved to a different  place, or when update information for new extensions become available.

If no actual update is available,  for example, there is just version 1.0, then the update information could still refer to this extension.  This does not do any harm because the Extension Manager compares the version number of the installed extension and the version which is contained in the update information, in order to display only real updates.

The location of the extension used as update could be the same as the location where customers download the extension for the first time. For example, there could be a web site which contains links to extensions.  Let's assume one link is:

http://mycomp/extension.oxt 

The extension references a feed at: 

http://openoffice.org/extensions/updatefeed.xml 

The feed contains the reference to the update information:

http://mycomp/updates/extension.update.xml 

and this file refers to the update which is again: 

http://mycomp/extension.oxt 

If now version 2.0 of the extension becomes available, then the publisher could simply replace the extension at http://mycomp/extension.oxt and change the update information so that it reflects the new version. This way, users download always the latest version from the website and the Extension Manager can use this extension as update for an older version which is already installed.

I could become necessary to change the server which hosts the update feed or update information.  If this results in a different URL for these files, then the automatic update will not work.  Therefore the following procedure is recommended.

1. Plan for a transition period, that is long enough for most users to get a new update. 

2. Set up the new server, or the locations for hosting the update information, and run both servers in parallel. That is, the same update information and updates should be available from both servers.

3.  Prepare new versions for extensions that contain  an URL to the new server.

4. Switch of the old server after the transition period. Users, which have obtained the update, will be able to use the update mechanism as before. All other users will not be able to get an update anymore. 

If the update information can be contained in a file which can be directly accessed through a URL or are generated on demand (HTTP get request). If it is a file then it could be named according to this pattern: 

<extension_file_name>.update.xml 

For example, the update information file for the extension myextension.oxt is myextension.update.xml. The .oxt file extension is not used. 

It follows the description of the XML structure of the update information data:

XPath: /description 

Parent element:  document root

Child elements: 

XPath: /description/identifier 

XPath: /description/version 

XPath: /description/update-download 

XPath: /description/dependencies 

XPath: /description/update-download/src 

XPath: /description/dependencies/dep:OpenOffice.org-minimal-version 

The description of the atom feed is available at: 

The following content of a description.xml directly references update information: 

<?xml version="1.0" encoding="UTF-8"?>

<description xmlns="http://openoffice.org/extensions/description/2006" 

    xmlns:xlink="http://www.w3.org/1999/xlink">

    <version value="1.0" />    

    <update-information>

      <src xlink:href="http://extensions.openoffice.org/testarea/desktop/simple/update/plain1.update.xml" />

      <src xlink:href="http://extensions.mirror.openoffice.org./testarea/desktop/simple/update/plain1.update.xml" />

    </update-information>

</description> 

The second src element contains a URL to a mirror which will be used by the Extension Manager if the location referenced by the URL in the first src element cannot be reached. 

This is the  content of plain1.update.xml:

<?xml version="1.0" encoding="UTF-8"?>

<description xmlns="http://openoffice.org/extensions/update/2006" 

             xmlns:xlink="http://www.w3.org/1999/xlink">

    <identifier value="org.openoffice.legacy.plain1.oxt"/>

    <version value="2.0" />    

    <update-download>

        <src xlink:href="http://extensions.openoffice.org/testarea/desktop/simple/update/plain1.oxt" />

    </update-download>

</description> 

The src element contains a URL to version 2.0 of plain1.oxt. Plain1.oxt has the identifier org.openoffice.legacy.plain1.oxt because it does not define an identifier in its description.xml. Otherwise the identifier would be the same as the one in the description.xml. 

This is the content of the description.xml of feed1.oxt which references an atom feed: 

<?xml version="1.0" encoding="UTF-8"?>

<description xmlns="http://openoffice.org/extensions/description/2006" 

    xmlns:xlink="http://www.w3.org/1999/xlink">

    <version value="1.0" />    

    <update-information>

      <src xlink:href="http://extensions.openoffice.org/testarea/desktop/updatefeed/update/feed1.xml" />

    </update-information>

</description> 

The feed: 

<?xml version="1.0" encoding="utf-8"?>

<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-US"> 

  <title>Extensions Update Feed</title>

  <link rel="alternate" type="text/html" href="http://update.services.openoffice.org/ooo/snapshot.html"/>

  <updated>2006-11-06T18:30:02Z</updated>

  <author>

    <name>The OpenOffice.org Project</name>

    <uri>http://openoffice.org</uri>

    <email>updatefeed@openoffice.org</email>

  </author>

  <id>urn:uuid:a4ccd383-1dd1-11b2-a95c-0003ba566e9d</id>

  <entry>

    <title>feed1.oxt version 2.0 available</title>

    <link rel="alternate" type="text/html"

        href="http://extensions.openoffice.org"/>

    <id>urn:uuid:a4ccd383-1dd1-11b2-a95c-0003ba566e9f</id>

    <category term="org.openoffice.legacy.feed1.oxt" label="feed1.oxt" />

    <updated>2006-11-06T18:30:02Z</updated>

    <summary>Click here to go to the download page.</summary>

    <content type="application/xml" src="http://extensions.openoffice.org/testarea/desktop/updatefeed/update/feed1.update.xml" />

  </entry>

  <entry>

    <title>feed2.oxt version 2.0 available</title>

    <link rel="alternate" type="text/html"

        href="http://extensions.openoffice.org"/>

    <id>urn:uuid:a4ccd383-1dd1-11b2-a95c-0003ba566eaf</id>

    <category term="org.openoffice.legacy.feed2.oxt" label="feed2.oxt" />

    <updated>2006-11-06T18:30:02Z</updated>

    <summary>Click here to go to the download page.</summary>

    <content type="application/xml" src="http://extensions.openoffice.org/testarea/desktop/updatefeed/update/feed2.update.xml" />

  </entry>

</feed>

The feed contains two entry elements and each references the update information for a different extensions. It could, however, also reference the update information for two different versions of the same extension.

The update information for the version of feed1.oxt:

<?xml version="1.0" encoding="UTF-8"?>

<description xmlns="http://openoffice.org/extensions/update/2006" 

             xmlns:xlink="http://www.w3.org/1999/xlink">

    <identifier value="org.openoffice.legacy.feed1.oxt"/>

    <version value="2.0" />    

    <update-download>

        <src xlink:href="http://extensions.openoffice.org/testarea/desktop/updatefeed/update/feed1.oxt" />

    </update-download>

</description> 

Extensions can add options pages to OOo's options dialog. It is also possible to start an options dialog from within the Extension Manager on behalf of a particular extensions.  An options page represents a child window that is displayed within the options dialog. An extension can provide multiple options pages. It can determine that they can be added to already existing nodes, such as “OpenOffice.org Writer” or  “Internet Settings”.  It is also possible to create completely new nodes.

The specification for this feature can be found at: 

The GUI of an options page needs to be created by the dialog editor of OOo.   Exporting the dialog will result in saving a .xdl file and perhaps  multiple .properties files. The xdl file contains the description of the dialog in XML whereas the properties files contain localized strings. For example, if the dialog is named Dialog1 and it contains strings which are localized for German and US – English, then you will obtain these files:

Dialog1.xdl 

Dialog1_de_DE.properties 

Dialog1_en-US.properties 

Please make sure that you have set the property “With title bar” to “no” for the whole dialog. 

The exported files can be anywhere in the extensions, except in META-INF. They must also be in the same directory. 

An options page typically allows the user to enter some data, which of course must be saved when the user presses the OK button. When the options page is displayed it should show the data which the user entered previously. In case nothing has ever been entered, the options page could show some “default” data or nothing at all. 

How the data is saved and where it is stored is not covered by the specification. It only defines the events “ok”, “initialize”, and “back” which the extension needs to process in order to save the entered data, initialize the controls with data, or restore the state of the controls with the previously saved data.  The “ok” and “back” events are triggered by the “OK” and “Back” button of the options dialog. “initialize” is called before the options page is being displayed. In most cases “initialize” and “back” have the same meaning.