james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Mailet API v2
Date Mon, 03 Jun 2002 13:33:38 GMT
Danny Angus wrote:
> I dont see why the LinerProcessor call to mailet.service(Mail mail)
> shouldn't be regarded as a request/response, with either a null response, or
> a Mail response which would be the original mail modified by the processing,
> and ready for the next step in the processor.
 > Nor why the SpoolManager in its role as the manager of the 
 > shouldn't like wise see the call to LinearProcessor.service(MailImpl 
 > as an identical request/response

The reason we don't is that
a) you could return as the response a message different than what was 
passed (makes it harder to handle)
b) we viewed it as a bad design to stick a new message in the middle of 
the processing chain.
c) many mailets would not "consume" the message, meaning they'd have to 
add extra code to set the response the same as the request.

What we might want to do instead of build another GenericMailet that 
consumes messages... then if someone wants to build a consuming mailet, 
they can just extend a different class, and they don't have to 
understand Mail.GHOST and other such stuff.

 > To that end it would be nice to have the Mailet SDK contain a complete
 > simple implementation which could be used by developers working on the
 > mailet API, mailet developers, and by users who aspire to add a simple
 > mailet context to their products.

Again, I think a "testing kit" might be a better approach.  Provide 
several dozen standard messages, let the user add whatever other ones 
they want to form a test suite for their mailet or matcher, then use the 
testing kit to run it and let them check the output.
Serge Knystautas
Loki Technologies

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message