@Developers: Your feedback needed

I have a request to the developers among our users. If you would write a plugin for WDS, which functionality would you like to provide to the users? …this question aims to find out which hooks to provide. Also if you have special requests what functionality of WDS should be publicly available to a plugin, your feedback is needed.

Planned are the following callbacks/hooks: in the report system (on every item by its full name), cleanup menu items (e.g. a plugin could come with some extra application and instead of actually deleting files it could output some kind of script), retrieval of command line options, colors of the treemap items according to whatever property of the item (which the plugin has to manage! – ownership, file extension or file category such as multimedia file have been suggested!). The following functionality is planned to be public: menu items in a new main menu item “Plugins” (mainly to allow the plugins to have a GUI for config purposes), retrieval of some context data inside the above hooks. Maybe some kind of re-branding (probably adding a new tab in the about box) will be allowed.

In all cases a plugin will be allowed to have one pointer which is opaque to WDS and which is used in callbacks (“hooks”). So you can store anything you want there and just supply the pointer to WDS upon initialization.

The plugins will not be loaded before a certain point and there will be a new command line option that allows to disable all plugins in case some plugin misbehaves – of course this command line option can not be overridden then. Also the plugins will be shown with the information that is supplied in special fields in the version resource of the file. This also means that every plugin must have a version resource.

Also there will be a mechanism that ensures that the application and the plugin agree with each other so that the plugin can be loaded. Both, the application and the plugin have the chance to bail out in case something does not fit (e.g. wrong version on either side). This does not only ensure compatibility of an older plugin with newer versions of WDS, it also allows a plugin to reject working together with a newer version – thus allowing for hotfixes to be deployed in the form of plugins if there should be ever the need (logically a new release would fix the issue so the hotfix plugin has to be bound to a certain version).

Last but not least the license of the plugin system will not be the GPL but instead some other license in the spirit of LGPL, MPL, BSDL or maybe even the ZLIB license. This is to ensure that developers of such plugins are not forced to reveal their source and thus encourage commercial vendors to provide plugins for WDS. However, developers are of course encouraged to join the WDS team and there will eventually be some official plugins and an installer for them …

// Oliver