The goal for Mailet API v3 is to eliminate all need for Mailets to access underlying interfaces provided by a mailet container that are not part of the Mailet API. For example, current Mailets require access to repository interfaces provided by Avalon. Additionally, Mailet logging will be enhanced.
Ideas so far.. Based on some hacking I've done, and undone but will re-do, it is a simple refactoring job to achieve a complete and clean seperation between James and the Mailet API for those services which are currently supplied by dropping through to container specific code.
Basically there has to be a mailet.Repository interface, specifing little more than store(Mail) listKeys() and retrieve(Key) This can then be extended to support seperate repository interfaces (if required, which isn't at all clear yet) for UserRepository and MailRepository.
This is supported by adding a single method to the mailet context, viz context.getRepository(specification) where specification IMO should be *either* a name or a URL but the API should not need to provide for both. At the moment James mixes names and URL's, IMO unnecesarily. Requires discussion.
[Progress: James and The API have been refactored to provide access to repositories via the API] [TODO: Database connections are still being managed directly through James, this still needs to be addressed.]
James could then continue to allow older mailets to access the Avalon layer, or could deny this access. More likely this should be manifested by a configuration parameter to provide explicit switching on of support for the older system. Requires discussion.
The next Mailet feature is Mail.addParameter(String name, Serializable value) and Mail.getParameter(String name) Although possibly restricting parameter values to Strings would provide enough added functionality, and ease implementation. Requires discussion.
The other main focus of v3 is extending the API to support enhanced logging. (Noel?)