next up previous contents
Next: Speed Optimization - Avoiding Up: Implementation Previous: Shared Library   Contents

Dynamic Plugins

One of our main goals with OpenVL was to make the library extensible. To realize this goal we use dynamic plugins. Dynamic plugins are basically shared libraries which are loaded at run time when the functionality provided by them is needed. Since these plugins are implemented as shared libraries, they provide us with all the benefits of shared libraries that we discussed before.

To provide support for plugins, OpenVL has another component called the Plugin Manager. For simplicity we left out this component when discussing the structure of OpenVL in the earlier sections. The responsibility of the plugin manager is, as the name suggests, managing the plugins. This includes finding all the plugins that are installed in the system and creating a database of the available plugins and the functionality they provide, loading the appropriate plugin when a certain functionality is requested, unloading the plugin when the library is finished using it, etc.

Figure 7: Use of dynamic plugins in OpenVL.
\includegraphics[width=\textwidth]{images/openvl-plugins.eps}

The plugin manager can load any plugin that implements a specific plugin API. To create plugins for a specific interface, the plugin API provides a mechanism by which the plugin can provide objects for the given interface if one exists in the plugin. This mechanism can be used to create plugins for absolutely any interface. In OpenVL, we use plugins for three main interfaces - the volume data layout API (Figure 3), the file input/output API (Figure 5), and the volume processing API (Figure 6). This means that all the different layouts, the file i/o filters for different file formats, and the various volume processing tasks are implemented as dynamic plugins. In Figure 7 we show how these plugins are laid out. The OpenVL library consists of multiple shared libraries - the core library and the various libraries that each implements a dynamic plugin. The OpenVL library itself comes with a set of plugins. Users can implement their own plugins and OpenVL will pick them up automatically once the shared object files are stored in the correct directories on the system. In Figure 7 we show the user plugins as third party plugins.

The plugins for data layouts and file i/o are internally used by OpenVL and are never exposed to the user. The plugins for the volume processing tasks are however meant to be used by the user's applications. To allow the user to query for an available task and use the plugin, we provide a Trader interface. This interface can be used to query the plugin manager for a specific task, say region growing. The plugin manager then searches through the plugins which implement the volume processing interface to find one which can perform region growing. If a plugin is found, it is returned to the user. The user can then use this plugin to perform the task she requested using the simple volume processng API introduced in Section 5.

The extensibility of the OpenVL plugins does not end here. Users can use the OpenVL plugin mechanism to create dynamic plugins for any interface they choose. For example, a volume rendering applicaton using OpenVL can create an interface for volume rendering and then implement the different volume rendering methods as plugins. OpenVL thus provides a very powerful mechanism which allows extending not only OpenVL itself, but any application that uses OpenVL.


next up previous contents
Next: Speed Optimization - Avoiding Up: Implementation Previous: Shared Library   Contents
Sarang Lakare 2002-12-23