Extension Layers

From Apache OpenOffice Wiki
< Documentation‎ | DevGuide
Revision as of 01:46, 17 September 2008 by TJFrazier (Talk | contribs)

Jump to: navigation, search

The Extension Manager uses two extension layers, the user and the shared layer. Extensions installed in the shared layer can be used by all users whereas those in the user layer can only be used by the user who installed them. An extension can be installed in either layer or both. In the latter case it is necessary to determine what extension is actually used when a client needs to make use of an extension because a client cannot choose the layer.

The idea of layers is that extensions in the top layer obscure the same extensions in the layer below. In other words, the extension in the highest layer will be given preference. Because the user layer is the top layer, a shared extension is only used unless there does not exist the same extension in the user layer.

This, however, is only a simplified model. An extension is never used as a whole. Instead clients access the particular contents, such as components, configuration data, etc. And it is also these contents which obscure the same content in a lower layer. For example, an extension contains a UNO service, which is installed in both layers. When the client instantiates it then the one from the top layer is used.

The version of an extension has no influence on the “selection process”. Even if the shared layer holds a newer version of the extension as the one in the user layer, it will not be used. However, there is a situation where contents of the shared extension are still used. Assuming there are version 1 and version 2 of an extension. Then the different versions may have different content. For example, version 1 may contain a service foo which is not contained in version 2. If now version 1 is installed in the shared layer and version 2 in the user layer then a client can instantiate foo from the shared layer. This is only possible because there is no service foo in the extension of the user layer.

The problem becomes more obvious when looking at configuration entries. Let's assume that version 1 of an extension adds a menu foo and version 2 adds menu bar. If one extension is installed in the share and the other in the user layer, then both menus appear. This is because the nodes of the configuration files are merged into the configuration and not the xcu files itself. That is, if the extensions contain an xcu file with the same name, then the xcu file of the last installed extension will NOT replace the one from the other extension. The second xcu file can, however, change the values for nodes which have been defined by the first xcu.

Unprocessed Content

This is content which, as the title indicates, is not processed at all. When installing the extension it is just copied to the install location. One should never try to access this content directly. Instead one should create a configuration entry as part of the same extension which contains the location of the content. When accessing the configuration item then the proper layer is used and one will obtain the correct location of the data.

There may be, however, difficult scenarios. For example, let us extend the previous example where the version 1 of an extension contains the service foo, which is not contained in version 2. Version 1 be installed in the shared layer and version 2 in the user layer. foo uses a piece of data which is also contained in the extension. To find the data foo could use the PackageInformationProvider. That service will, however, return the location of the extension of the user layer in this case. But the data may or may not exist in version 2 or it may be incompatible with the one from version 1 of the extension. Because foo is part of version 1 it may not work with the data from version 2. Another option would be a configuration entry pointing to the file. But if the node name is the same in both versions of the extension, then again, one would obtain the data of the user extension. Obviously, the node name must be different, so that foo gets the data from the extension which it is part of.

The Future of Layers

As seen in the above paragraph one can run in problems because the layering is based on the respective extension contents rather than on the extensions itself. Another big problem is, that because of the layering, an older version of an extension is used even though there is a newer version installed. This happens when the user installs the old version in the user layer and the administrator installs the newer version in the shared layer. If we invented a third 'bundled layer', then this problem deteriorates. Let's think about a user who updated a bundled extension, say, the french dictionary. Later, the user installs a newer version of OOo or an OOo update, which brings an even newer dictionary. Now the user would not profit from the latest dictionary, because she once installed the dictionary on her own. From the users perspective OOo just behaves daftly. One could think, of course, of a notification for the user but there are two grave implications:

  • when does OOo check for inconsistencies?
  • how can this be explained to the user?

Think about a message, such as: "Dear user. You cannot use the latest version of the french dictionary, which is installed in the bundled layer. Instead the dictionary which you installed earlier is used. You need to uninstall it, if you want the new version ...."

I guess this is a 'user experience' nightmare. Therefore we are thinking about a new approach, which we think is easier to be understood. The idea is to base the decision about what extension is used solely on the version of the extension. Then only the contents of this extensions are used. That is, even if other versions of the same extension are installed, they would have absolutely no effect on the system. In this way, the selected extension would obscure completely all other versions of the same extension.

To not get confused we'd dub the layers 'repositories'. That is, there would be a user repository, a shared repository, maybe a bundled repository, etc. The number of repositories would not matter. This design would it make easy to add additional repositories, for example one for shared extensions in the office' basis layer.

Content on this page is licensed under the Public Documentation License (PDL).
Personal tools
In other languages