Difference between revisions of "Documentation/DevGuide/Extensions/Extension Layers"

Revision as of 09:29, 21 January 2010

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.

The idea of layers is that extensions in the top layer hide the same extensions in the layer below. In other words, the extension in the highest layer will be given preference, when resources from the extension are requested. 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. The version of the extension has no influence.

Hiding does not work

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.

There are situations where contents of the shared extensions are still used, although they should be hidden and therefore not usable. 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 foo is still around and can be instantiated. Foo may access resources which are also delivered with this extension and are also available in version 2 which is in the user layer. Resources in version 2, which hide those from version 1 (same node in xcu or same service), can be incompatible, so that foo fails.

A service may also need files which are part of the same extension and which are only directly accessible. That is there is no API, such as the registry or service manager, which can provide the content. A "running" service does not know from which layer it comes from. To get the install location it can use the PackageInformationProvider. This service will first look into user layer and if the extension cannot be found, then it will look into the shared layer. If now the service from the shared layer needs some file from its extension, then it may accidentally use the one from a different version of the extension in the user layer. This file can be incompatible or not even exist and make the service fail.

Another example can be constructed using registry values, which are contained in xcu files. 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.

These examples prove that the layering (in terms of hiding the items from the layer below) on extension level does not work, although it does for the respective deployment items. And it may be safe to say, that this goes against the user's expectation.

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.