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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
