[Webical-developers] Plugin development

[Ivo v. D. <ivo...@gm...>]

Hello,

In order to get the plugin framework somewhat stable and complete I've
started reviewing and expanded it. I'll do this in two steps: first the
backend and then the frontend. I've decided to do this by developing some
plugins in parallel to get the requirements clear in a practical way. For
the the backend plugin I've already started on a caldav provider, I'll
decide on the frontend plugin later (thinking off a google maps plugin).
While working on the plugin a couple of issues/missing features already
popped up together with some infrastructure needs to make development
easier. I'll list them here for now.

Infrastructure needs:

- A maven repository to deploy webical classes to. This enables plugin
developers to add webical as a compile time dependency.
- A webdav location (or just web with some other form of upload) to deploy
the plugin manifest xsd. This makes it possible to reference the xsd online.
- Nigthly builds that can be deployed to the maven repository (through
continuum?).
- An svn restructuring to accommodate the plugins developed in-house. This
could be done as a separate project or by dividing trunk in /webical and
/plugins.
- (Optional) A location to upload (nigtly) builds for the plugins.


Webical enhancements:

- Extension the pom so that a jar is created with the classes to upload to
the maven repository.
- The possibility to include jar archives in the plugin:
   - Extend the manifest xsd.
   - Extend the plugin classloader.
- Add dependency information in the framework
   - Add a version number in the web.xml or
applicationContext.xml(generated by maven)
   - Add a compatible-webical-version in the manifest xsd
   - Extend the Plugin registration system to check for the version numbers
and only enable the plugin on a match.

Possible desired enhancements:

- Add a search method to the EventDao and manager to enable search on the
calendars.
- Extract the synchronization logic from the provider specific details so it
can be reused by plugins (a google calendar provider for example).
- Plugin framework enhancements:
   - Add additional possibilities to describe the plugin:
      - An version number (required)
      - A description (required)
      - A static html page to display additional information like licenses,
developers and that sort of thing)
   - Add configuration options
      - Global settings. Give the opportunity to supply a configuration
page. The configurations are stored in the database.
      - User settings. Give the opportunity to supply a per-user
configuration page. These configurations are stored in the database as well.
   - Divide the configuration page in steps where the plugin configuration
has a separate tab.
   - Add a list of plugins with the state (plus reason why they are not
enabled), info and a link to the optional info and configuration page.
      - Debug info can also be added. I'm thinking of a page that shows the
registered classes, jars, resource directories, backend providers
used/offered extension points, etc.

There are probably a lot more features that can be thought off, so I'll
start a topic to list these and let it serve as a base for additional
requests and discussions.

Regards,
Ivo

-- 
Ivo van Dongen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500