Noel J. Bergman wrote:
Agreed on all of the above. As you might notice, I have been reviewing the
commits, was not asking for them to be reverted, and was raising a general
issue based upon a recent pattern.
I'm sorry if my english is not good enough to let you understand my mood ;-)
I wanted only to explain the behaviour and I was happy to see your point
and I wanted to inform you (and others) on the logic I followed to
decide what to include and what not to.
Both you and Norman raise the issue that "creating multiple optional
handlers would have been code duplication and more difficult to mantain in
those cases." That suggests looking to see if we can factor out more common
code, such that the handlers are more function specific and less common
scafolding.
The problem is that Handlers are not aggregable: you can use a single
RCPT handler right now, so if you want to check domain validity for the
recipients, check maximum number of recipients, and use tarpit all
together you can't do that we we provide that functionality in different
handlers.
I certainly don't feel that the current form needs to be, or indeed is going
to be, stable. What we have is a first cut at a major functional area.
We are still in alpha stage: I think that both minor features and
refactorings are welcome.
Maybe this helps someone else to think about new solutions that allow us
to have multiple handlers for a single command or any other fix for the
feature bloat.
We should decide what to do with additional mailets/matcher/handlers in
general: we currently don't have a repository and a website where to
publish those additional stuff but we can't continue adding each new
mailet to the james core.
Good timing. I was going to suggest that it might be good to provide a
second package of matchers and mailets, not part of our core, to show people
how to do those. Also, it would provide us a place to put some
non-essential samples, or even deprecated matchers/mailets, such as the old
list server. We could extend and generalize that idea, perhaps. We could
also revisit the idea of handler packages to see if we can avoid having to
specify each one separately.
We should provide source and binary distribution for every additional
package.
We could create a bundle for the mailing list stuff, another for the
smime stuff, but most of other mailets have specific goals and are
difficult to aggregate in rational/logical packages.
I think we should find a temporary solution until someone will have time
to work on this and improve the current one: I think we should continue
to include standard/common behaviours in the core and leave specific
handlers/mailets/matchers. Future refactorings will improve that.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
