Michal's Design Study

Revision as of 08:55, 3 October 2009

The Problem

Many clubs or charitable organisations are staffed by volunteers, or staff with little training in computer use. Commonly used software (such as Micrososft Office, or accounting packages) are complex and can be difficult to use due to the vast array of options presented to the user. Most of the features will never be used by a particular person, yet all options are available regardless. This can leave users bewildered and unable to figure out which option they want.

Furthermore, some tasks require the use of multiple pieces of software. Integrating these creates another layer of complexity on the users part. For example, to create a contact directory for members, it can either be all typed up manually, or a database created and then combined with a template to create the directory. One option is more time consuming and error prone, the other more conceptually difficult for a novice user.

The Solution

I propose to create integrated, modular systems tailored to individual organisations. Customers would be able to choose from a variety of prewritten components, or choose to have custom components created, if there are not prewritten components to suit their needs. The first step in doing this is to build a plugin architecture which will support the loading and linking together of these components.

Requirements

The basic list

• Load required libraries for each component
• Create instance(s) of components
• Link components together

A little more detail

The basic function of the plugin system (henceforth known as PluS) is to load and activate plugins. Information about each plugin will be stored in an XML file, in a known location. Using this information, PluS will add the plugin's jar file to the classpath, create an instance of the plugin, and activate it.

PluS plugins can also declare dependencies and extensions. A dependency of a plugin is another plugin on which the first plugin relies. An extension of a plugin adds functionality to the first plugin. Any plugin is able to be depended upon. However, only plugins which define one or more extension points are able to be extended. In a dependency - dependent relationship, the dependent observes the dependency, while in an extension point - extension relationship, the extension point observes the extension, passing commands on to it as needed.

Just to throw a little extra into the pot, some basic logging functionality is always useful for debug purposes/spy work/remembering what you did or didn't do. It's a lot easier to switch one flag and change to a silent logger than to find and comment out every single printf statement in your code.

PluS in Action: An example

AddressBook is a contact directory, Boris is a VoIP application which defines an extension point for alternative dialing methods, and Calla is an extension for Boris which integrates with GTalk video chat. Boris doesn't have it's own contact list, but instead depends on AddressBook. As Boris first loads, it asks AddressBook for a list of contacts to display. When Calla is registered as an extension to Boris, an option is added to Boris' menu to call a contact using GTalk.

Mr. U. Ser decides to chat with his friend Wal using GTalk. U. Ser finds Wal in the contact list he can see in Boris. He chooses "GTalk chat" from the menu. Boris tells Calla to call Wal using the username from Wal's information stored in AddressBook. Calla calls Wal and notifies Boris when the call connects, so Boris can display the video feed. When the call disconnects, Calla notifies Boris again.

Stuff I currently need help with

Plugins shouldn't be loaded if not all their dependencies are there. However, their dependencies may exist but not be loaded until later... Any ideas on how to deal with this? Information on each plugin & its dependencies etc is given in a separate xml file.

I need a better name than Boris for my example. Preferably something starting with B that is related to VoIP.