Federico Barbieri wrote:
> Take a look at Pier and Stefano Mail Servlet draft. I't very elegant and
> incredibly simple to use. It lacks of some smart way to clone the body
> into the response without pain but that's not so difficult.
I took quite a long look at their proposal before coming up with my
own... the reason I don't think there's work is because you are
"filtering" email messages... not "responding" to them... Common mail
servlets I envision are loggers, signers (add some unique key to
authenticate it came through your server at time X), rerouters (mailing
lists, aliasing), and modifiers (attaching disclaimers, other notices...
I guess signers technically fall under this larger category).
Like I said before 95% of the time you are doing nothing or very little
to the email message. A request/response paradigm supports the response
being very different from the request... generally unrelated... in HTTP,
your information comes in like param1=value1¶m2=value2 and goes out
like <html><body>Hello world</body></html>. This metaphor really
doesn't work for mail servlets, IMHO.
> I like the idea of a MailServletequest and MailServletResponse since
> this patter is really evident and well known. But since this do not
> allow forking... consider this:
>
> public void service(MailServletRequest req, MailServletResponse res)
>
> MailServletRequest gives you methods to easily access routing info,
> headers and read body
> MailServletResponse has some methods like
> copyBodyFrom(MailServletRequest req) and copyMailFrom(MailServletRequest
> req) etc to make easy and painless duplication of messages.
Exactly... most of your mail servlets will run copyBodyFrom every time
they're run... even if they are doing nothing. Say you have 10
servlets... 1 logger incoming, 1 anti spam, 2 listservs (each had
different functionality), 1 aliasing/rerouter, 1 quote generater, 1 joke
generator, 1 disclaimer attached to your mail server... maybe a couple
of others. EACH ONE is going to call copyBodyFrom, which just seems
like a huge processor drain, aside from making the servlets more
complicated to write... if they don't want to do anything to the
message, they should just be able to return;
I would really say a clone would be better... you have your Message and
delivery wrapper object passed to you... you clone one, call setSender,
setSubject, and add it to the queue (that's the one part you'd have to
add support for). These setSender, setSubject, and many other methods
are readily available from the JavaMail API on InternetMessage... I
don't see the need to create a new object which duplicates these
methods.
This is just how I was thinking mail servlets would be used... probably
the biggest first use of this is listservs and aliasing/rerouting. But
let's design beyond that if possible. ;)
Serge
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
