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] Logging Proposal
Date Mon, 10 Jun 2002 22:38:28 GMT
Andrei,

The mailet API was supposed to be a Java standard for writing mail-based 
applications.  Long ago (4 years?) some java.apache.org folk submitted a 
proposal to the servlet group for mail processing.  As their proposed 
API modeled the request/response nature of the servlets too much, the 
servlet Sun folk declined on the idea as they saw mail processing as 
more analogous to filtering than responding.  There was a page on 
java.apache.org about JAMES with a declined proposal, and no code.

Then in early '99 I donated the original codebase, and a bunch of us 
went through this machination to design this mailet API (not to mention 
name it and refactor my code massively).  This is how mailets got 
defined, and JAMES turned from a concept to code.  JSRs weren't around 
yet (and neither was jakarta.apache.org), so it was never submitted as a 
standard, and those discussions happened on java.apache.org listservs 
(and I hope someone can find them).

Since then, procmail has been taking off, sendmail is getting some mail 
processing capabilities, there is the sieve RFC that does something 
similar, and there are half a dozen java (some open source) mail servers 
out there with thoughts/goals of doing this.

The mailet API was conceived and designed to be a standard that other 
mail servers could support.  This principle led to creation of the 
mailet API, which has provided a simple base for mail based apps.  It 
doesn't define everything that most apps will need (like logging, being 
the most recent heated topic), but it defines lifecycle, it defines the 
necessary objects, the relationship between mailets and its container, 
configuration, and processing concepts.

I just checked the James project website, and I can see how this website 
has contributed to the confusion.  "Mailet API" has been replaced with 
"Apache Mailet API", and there are no notes summarizing the many months 
of discussion that created this API.

I don't know how, but it seems in the past few weeks the listserv has 
sparked a discussion of rebuilding this API from the ground up.  As I 
don't have the time to summarize notes, I can't expect or even honestly 
ask people in today's discussion to go read the mail archives to see the 
points made and consider what many other authors had put forward.

I think it might be good to request a JSR for mailets at this point.  I 
feel it might be difficult to get the James and Avalon developers to not 
tweak the API towards their design pattern preferences.  Maybe the JSR 
can call these something different, and James and Avalon developers can 
elect to implement their own API instead at this point.

Anyway, I wanted to share some history so everyone understood how we 
ended up with what we have right now.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com

Andrei Ivanov wrote:
> I think there is still principal question which has to be addressed first.
> The question is: will Mailet be Avalon dependant or not?
> If Mailet is clean from Avalon then logging can be removed from Mailet API,
> but if Mailets will be Avalonized then logging must (more precisely may) be
> in API. Before this is decided no further speculations make sense.
> I don't see anything against Avalonization of Mailets.
> What is the bottom line of this discussion since James runs on the top of
> Phoenix and Phoenix is on the top of Avalon? What is still not Avalonized in
> James (like Mailet API) shall be Avalonized, or... whole James has to be
> rewritten from ground up to keep it consistent with something else than
> Avalon...
> Andrei


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


Mime
View raw message