Noel J. Bergman wrote: > I was not criticizing. I was simply pointing out that this is how the > current Mailet API supported what you had asked me, namely what to do about > mailets that want something, e.g., a repository, that is not supported on a > specific container. I then further noted that (since this mechanism uses > Avalon Frameworks), that Best Practices with the Avalon Frameworks > programming model would work a bit differently, and I gave an example.
Ok, then I'm not sure why you're discussing changing the mailet API. What need is not being met? Is it just complete portability? What functionality do you think should get incorporated into the mailet API then? >>Ahem... JSR 47 HAS produced a common API for logging. It's called >>java.util.logging. > > > True ... but it is neither in the Servlet API nor exposed to Mailets, which > was sort of the context of the discourse. Sorry, but from my view this discourse went like this... you were advocating adding logging to the mailet API. I said there are too many ways and pointed to the fact there are many implementations. You said there are so many implementations only because there was no common API. I'm pointing out how their was a JSR and so there is a common API. So, tracing it back, I think there are multiple implementations not because of a lack of a common API... it's because there are different needs. There are different needs, so we shouldn't add this into the mailet API. We provide log(), which is basically an equivalent of System.err. If a developer wants serious logging capabilities, he/she can either use what comes with the JDK, use Avalon's logger, or whatever third party library they have around. I don't think adding some other jar is a violation of the mailet portability nor using JDK 1.4 logging as a violation of it. Sorry, I don't mean to sound like a broken record, but I just wanted to clarify the context of the discourse as I remembered it. > Wait, I have not said that James + Avalon Frameworks doesn't do something! > I said that a Mailet API *WITHOUT* Avalon Frameworks is anemic, and that if > we don't specify how to fill the gaps (using the Avalon Frameworks is one > way), then those gaps will be filled with vendor-specific solutions, and > that is the thing that is unacceptable. Again, I'd like to hear what you want to add to the mailet API. Again, from my perspective most of the conversation talks about Java and programming language concepts instead of concrete concepts to change in the mailet API. >>You've got a mailet API... you've got composable, etc-able >>interfaces that you can get as servlet context attributes. >>You can log, you can store, and whatever else that the >>Avalon-framework is providing. > > > Exactly! And I want to be able to RELY upon that regardless of whose > container implementation I'm using. That's it exactly! I guess I would only suggest you take a look at the "competing" solutions to mailets right now. They are very processing-centric, basically they are to SMTP what CGI was to HTTP. Few of them have any concept of user repositories, message repositories, application logging, or other enterprise mail server features. None of them really grasp the power of Java, and that's hopefully part of why mailets are the right answer. But I'm not sure if we need to create new API (and especially need to touch the mailet API) to support these concepts. Maybe we can map out what we need in terms of "Enterprise Mail Server Services" and find existing Java APIs that fill these needs. For user repository API... well, JNDI would work, right? The current user repositories could be exposed as JNDI resources, and the non-portable mailets could be changed to work against a JNDI resource. Then message repository API we build as implementations of JavaMail's javax.mail.Folder (actually doesn't look as irrational as you might think). Logging I think is pretty easy... JDK 1.4 is readily available, or heck we're on Avalon-framework so just use that API. Database access... well, I've really really wanted to expose the db pooling as a javax.sql.DataSource as that would just make a ton of sense and make the mailet more portable. I think the more we rely on other existing Java API, the easier it will be for mailet developers to get up to speed, and ultimately the more portable mailets will be. > --- Noel [off to get some sleep before ENG v NGA in a few hours] Good luck! -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
