SE401:33:Plugin Analysis
Initial Thoughts
Before we began looking on how to develop a plug-in interface we thought it would be quite simple.
It would require an interface (or equivalent in .net/VB) with predefined methods like:
- Variables to describe name/functionality, input type(s) needed etc.
- This raises problems, how do you deal with plug-ins that require more than 1 data input?
- Could be resolved by creating applications to merge data into 1 source.
- This wont work if the data sources are incompatible - might be easier if we make the plugin take an array of data sources.
- Function(s) that process input data.
- Function to output source code.
- How to display a static version of the content in the editor.
- Need to create a way to scan a directory for installed plug-ins.
- As the tool is for users with low computer skills we probably don't want them to be going off to sites and downloading/installing content themselves. It would be preferable to make this part of the tool - could do this similar to the bit torrent Client Azureus' approach - downloads a list of plug-ins from the site, and can tick the plug-ins you would like to install and press download. They are automatically installed and activated upon restart.
- This brings more issues - who wants to restart the application after downloading a new plug-in - we should find out if its possible to develop a hot pluggable tool (? is this the right term - start plug-ins while tool is running).
- We would need to create a method of checking for plug-in updates so users do not need to manually check.
- Added to user stories - See Plug-in specific stories
Research
MSDN site makes it sound very easy to create a plug-in framework - they even have a guide on how to do it
MSDN Creating a Plug-In Framework
- Note: Also has guides on making GUI's
This doesn't address making hot pluggable tools, but Java can do it so surely .net does...?
- Brief read over the MSDN guide would suggest it doesn't as you need to modify a .config file before the plug-in can be used, we will need to automate this for the user. Restarting the application is not a huge deal though - more of a user convenience.
Final Thoughts
- We will initially build the framework without plug-ins (functionality will be part of the framework).
- As this is an XP project we can choose to add plug-ins at any stage.
- Will involve a bit of refactoring but should not cause any major problems (maybe 1 iterations worth).
- Will discuss with Gill and see if she agrees.