james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Perry" <d.pe...@netcase.co.uk>
Subject RE: new mail list implementation (partial)
Date Wed, 08 Jun 2005 08:58:41 GMT
> Cool,
>
> That will be another source of information that will be extremely helpful.
>
> One of the design ideas I had was to use the "Chain of Responsiblity"
> pattern which will allow functionality to be added in stages and make it
> easy to configure.  Adding new features could them be done quickly
> without disturbing existing functionality.
>
> I'll work up a quick class diagram tonight to show what I have in mind.
>
> Chad
>

I'd be interested to see this.

I guess the closest pattern to my code is the command pattern.

Identify mail as message or command
message-->process list message
command-->pick command and run it

The reason i used the helper interface was to try and keep all code for
getting (and eventually modifying) list settings/membership separate from
the mailet, for two reasons: 1) resuse the helper in any management apps, 2)
new list stores only need to implement one interface - no code changes.

That way, implementing a new repository (eg JDOM xml version) for the list
is pretty straight forward - satisfy one interface, and specify the class in
the config, together with any options.

Similarly i was intending to specify an interface for archiving - so this
could be done straight to database, or through an NNTP repository depending
on the archiving implementation specified in the mailet config.

I have merely copied the current command code from the commandlistserv. I
never really played with it much.  The problem i can see when adding
commands, is that they will probably require certain new functionality in
the helper interfaces. E.g. implementing a digest command will require the
helper to handle a digest flag for each subscription.  I was thinking of
perhaps redoing some of my code so that each subscription and mailing list
has a map of string attributes - this would be more flexible as for example
adding a digest flag would require no code changes in the storage. However
i'm not sure how well this would map to say an LDAP repository, so i stuck
to hard coded flags.

If anyone has a chance, then please comment on the code, and what you would
like changed.  I feel it's a bit of a sloppy implementation, but hopefully
it does keep things open to enhancement.

Daniel.



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message