The Mechanics of a Plugin Framework

The host application processes the data it receives—whether it's a log file for the log-parsing engine, an HTML file for a web browser, or another type of file. Its work is completely unaffected by the presence of the plug-ins or their functionality. However, the host application provides a service to the plug-in modules.

In the case of the log-processing application, its sole responsibility is reading the data from the files, recognizing the log format, and converting that data into the appropriate data structures. This is the service that it provides to the plug-in modules. The main application does not care whether the data it has produced is used by any of the modules or how it is used.

The plug-in modules largely depend on the host application. Let's take the plug-in that counts the number of requests as an example. This plug-in cannot perform any counting unless it receives the data. So the plug-in is rarely useful without the main application.

You may wonder why you should bother with this separation at all. Why can't the plug-in modules read the data files and do whatever they need to do with the data? As we discussed, there might be many different applications performing different calculations with the same data. Having each of those modules implement the same data reading and parsing functionality would be inefficient from the development perspective—it takes time to redevelop the same process again and again.

Obviously, this is a rather simplistic example. Quite often, the end user does not notice this separation between the main application and the plug-in modules. The user experiences the application as the combined result of the application and the plug-in.

Let's consider the web browser example again. The HTML page is rendered by the browser engine and presented to the user. The plug-in modules render the various components within the page. For example, the Adobe Flash movie is rendered by the Flash plug-in, and the Windows Media files are rendered by the Windows Media plug-in module. The user sees only the end result: the rendered web page. Adding new plug-ins to the system simply extends the functionality of the application. After deploying a new plug-in, users can start visiting web sites that did not display correctly (or at all) before the plug-in was installed.

Another great example of the plug-in based application is the Eclipse project (http: // eclipse. org/). It started as a Java development environment, but has grown into a platform that supports multiple languages, integrates with various version control systems, and provides for modeling and reporting—all thanks to its plug-in architecture. The basic application doesn't do a lot, but you can extend it and tailor it to your needs by installing the appropriate plug-ins. So the same "application" might do completely different things. To me, it's a Python development platform; to someone else, it's a UML modeling tool.

Was this article helpful?

0 0

Post a comment