We've made a lot of progress on stability and even some new features for
JAMES recently. In an effort to hopefully remove some dependence on
Avalon (for mailet writers) and hopefully make the mailet API a bit more
complete, I've started to restate the mailet API in an Avalon-free
setting.
I've done a ton of rewriting on the sample matchers and mailets and have
started to build implementation classes for JAMES that would handle this
new API. My biggest goal was to no longer have mailets and matchers
required to extend an Avalon based object. Instead, mailets receive
Mail, MailetConfig, MatcherConfig, and MailetContext, for which JAMES
has MailImpl, MailetConfigImpl, MatcherConfigImpl, and
MailetContextImpl. This makes the mailets more independent, and helps
distinguish what is Avalon supplied functionality and what is mailet
functionality.
The goal of a migration would be to:
1) not affect the conf files
2) rewrite all existing matchers and mailets to new API
I'm hoping that with these objectives met, we could safely make a new
version release at some point in the future and not alienate many people
(I haven't received many comments from people writing their own mailets,
and even if they did, this ideally simplifies writing).
Really, there isn't a huge difference to the bulk of the API... just a
separation of what I thought was mailet API methods from implementation
specific methods, and then reworked how configuration happens to some
extent to remove dependence on Avalon and make it more unified with the
servlet API. I'm guessing this'll be the most contentious issue as I've
moved the mailet API to a simple name/value init parameters. While the
flexibility of nesting attributes in XML seems appealing, in my mind in
complicates the API, and in fact, none of the mailets we have right now
even use nested attributes... the closest thing is supporting multiple
forwardto elements, and this could just be a delimited value.
Please let me know what you think of the new API so far...
http://www.lokitech.com/~sergek/mailetdocs/ I'll continue to Javadoc
more stuff as I go and might need to add a few methods as I finish
porting all the mailets... not all the classes/interfaces have a top
level descriptive comment, but I think just about every method in every
class/implementation has one.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
