Thanks for your feedback.

JAMES is based on Avalon. Avalon is dead. JAMES can't handle my PERSONAL email load without being restarted nightly. JBossMail runs stable (minus my hardware failures which is a longer story).

I guess the case for mail services wasn't clear. I'll dismissively throw down the hammer. Here is the state of things:

* Javamail - is a total piece of crap. Its slow and over-complciated, the appserver bindings are -- dumb for a serious mail application

* JAMES - is based on Avalon which was a very bad (fatal actually) design decision. JAMES is horribly untestable code. JAMES is pathetic and can't be scaled (in part because of Javamail). (BTW I dug into JAMES while figuring out what could be done to implement IMAP ;-) so before you argue know the JAMES codebase and actually RUN it) and thats part of what lead to the JBMail idea. I'd planned to launch a mail server project prior to joining JBoss) -- Because there is so little implementation of value in JAMES, I'm very uninclined to collaborate. There may be room for collaboration on a replacement for JavaMail ( even if it seems like I just like to reinvent everything which isn't really the case hey not having to load the entire mail into memory might be a really neato feature don't you think!) -- the JavaMail interfaces (which really suck BTW) could be wrapped over the new stuff. However, I think of this in the same context of "lets wrap hibernate with CMP" (sure you CAN but you then add a lot of suck to hibernate).

* Enterprise-grade Clustered mail servers (of any real market acceptance) - Name them. Really there are two. Domino and Exchange.

* SPAM and the STATE of mail - I get more spam than mail and even with the greatest spam tools. Through collaboration with other open source projects we can come up with a system to enhance and exceed current protocols and systems that works for most people. (80-90% of users)

* Exchange....well....tool wise and feature wise -- Exchange rocks. Cost and *actual cost*-wise....it's not so hot.

* Sendmail/Postfix and the lesser "heavy lifters" of the internet are BITCHES to configure correctly and lack the tools and support of Exchange.

*Nothing ever replaced LotusNotes/Domino in mail-driven-application features. I'll detail these after the 1.0 release. For 1.0 in this area we'll work on maillets and mail scripting features as well as J2EE integration.

*J2EE/JBoss/Appserver-based applications in which mail is a principal application component -- it does not make sense to send to ONE SMTP server and then another. You need the data on the success or failure in reaching the target SMTP server HERE not in some intermediary. You can kludge your way around this but that's what it is. It is not pretty.

I tried to lay that out and the beginnings of a solution in "the case for mail services", but I guess I didn't do as great of a job.

Lets address your points specifically:

- This project has no planned architecture (let alone design). It desperately needs one.

That's simply unfounded. As for a BFUD as the XP crowd calls it, okay thats true... Since I never read those, I don't write them either. Instead there is a pretty clear architectural motif and list of reasonable objectives for the near future. There is a vision document -- hey if it wasn't clear (some "got it" some "didn't"), maybe in a couple milestones I'l revise it.

- This project does not have genuine selling point other than that it is "the same old mail services only this time on JBoss" (yes, I have read "the case for mail services")

I'm not on the marketing side, this project addresses several problems I've encountered as a mail user, system programmer, application developer and consultant. Its rather early (Milestone 2 will be out in a few days, I'm working on a little install config tool for it) to come up with marketing literature.

- This project is too unfocused in deployment of effort and feature delivery (for instance, the integration with Nukes bit - that's way too early to be a target)

Its pretty volunteer-based at this point so thats not likely to change in the near future. GO IMPLEMENT BETWEEN COMMAND TIMEOUTS NOW! (http://www.jboss.org/wiki/Wiki.jsp?page=MailServicesMilestone2Timeouts) If you go and do that then maybe I'm wrong in my assumptions, but if you don't then hey I'm taking what I get and guiding folks in their areas of interest along a set of objectives. On the specific example (nukes-integration), I agree. It was a mistake. I hope to have time to make more mistakes in search of the right decisions.

- If I see another custom, application-specific user/group management implementation I am seriously going to scream!

Yeah, thats why there is only a "StaticUserRepository" in M1/M2 which is kind of a silly implementation (though if you look -- the interface and preliminary design decision is actually pretty clear). Its a placeholder. Someone just contributed a JBossSX-based version. Once M2 is released I'll commit it. I'm toying around with more specific permissions though for IMAP. I hate ACLs to be honest but it may come to that.

- It's dangerous (even suicidal) to tie an enterprise application to tiger just yet. For most big enterprises 1.3.1 is still a "standard" JVM.

We haven't. I kicked it about, but for now, since I'm on OS X which doesn't even have a 1.5 JDK yet - its 1.4.x. I actually challenge the 1.3.1 assertion. I spend most of my time on the road consulting for JBoss at big enterprises (hence the slow pace of development). None I've visited recently are running 1.3.1 and if they are parallel garbage collection is usually compelling enough. Since the 1.0 release date is still many milestones away, I'm non-committal to stay 1.4 compatible. SSL over NIO would pretty much mandate 1.5. I'm non-committal that we won't change gears and go NIO if my benchmarking proves promising.

- No lessons seem to have been learned from the experience of Apache James (the big draw for me in James was the ability to write Mailets, but it failed evaluation for much the same reasons as mentioned above and that have been previously posted in this thread).

That is unfounded. We're only at Milestone 2. Lots of lessons were learned from JAMES. I even ripped of the stuff I thought was good. I haven't gotten around to properly ripping of mailets. We're not done finding the tradeoff between how to represent messages as a flexible object model yet maintain high throughput. Support for spam assasin, webmail ,etc are all in the works. The schedule (http://www.jboss.org/wiki/Wiki.jsp?page=MailServicesPlan) changes, the plan evolves based on contributions, availability of people to work on it. Pretty much everything mentioned in the above thread is "stuff that we have planned but haven't gotten to yet". Only we're not tied to a big fat dead mega-framework-philosophy-project-slash-framework that makes everything hard to implement ;-) we just have not even half the people working on it and haven't been at it even 1/10th as long.

- Decide first and foremost WHAT DOES THIS PROJECT GIVE AN ENTERPRISE OVER AND ABOVE SENDMAIL etc or EXCHANGE? Find the single line answer to that question that is sufficient to convince anyone whether commercial or technical.

It is the compromise between more bare bones mail services such as postfix and sendmail and Exchange. It can work in both situations. Moreover, compatibility with existing Outlook/etc infrastructure with no license fees. Lastly, features which properly support mail-driven applications. I did describe some of the problems we wanted to solve. I don't really hope to sum it all up in one line. That is marketing, I'm not in marketing. My audience for the next several milestones is like-minded geeks.

- Focus first on user/group management and figure out how to reduce dependencies to the point where it is NOT destined to be an inextricable module of the mail services.

Thats already done. You can plug in different implementations. The present interface is a bit over-simplistic at the moment and will need to grow once we add IMAP. Granted, it wasn't my focus for M1 - for M1 guess what it was "code should run and deliver some mail". M2's real focus was "don't loose mails and stay up reliably". M3 may be features or speed -- haven't decided.

- Deliver the IMAP so that a webmail interface could be built.

Thats in the plan. Again, thats a big thing to demand on the second milestone. Anyhow, IMAP isn't that hard really. Its just another text-based protocol. Now FAST and COMPATIBLE WITH LOTS OF CLIENT IMAP is certainly some effort. We'll focus on the Mozilla-mail and Outlook clients (we must always have two because they "accept" different things) on the three most used client platforms (Windows, Linux, OS X -- selected in part because I have them all, in part because all three do different things with end of line characters). BTW IMAP isn't required for webmail.

- Steal the mailets idea from james - yes, even the source as a start point.

I thought you read "case for mail services" -- that was in there :-). However, the code is not useful....honestly. I did "steal" other code from james that was useful.

- Look forward a bit and realise that you must ditch ejb2 entity beans and build on ORM (hibernate) - later provide an ejb3 implementation for java 5 when people actually want it

Thats actually planned. I was waiting for the Hibernate Deployer and SessionFactory management in JBoss 3.2.6/4.0. Secondly, its intended to be pluggable. (Yes I have a really good reason to need this pluggable). You'll hate this but I think every "pluggable" thing of substance needs 2 implementations to prove its pluggable. Do the easiest one first (and AT THE TIME, it was easier to do CMP).

- Drop any other integration effort for the time being

With nukes thats pretty much agreed to and done (we had a good reason for doing it but it didn't work out). However, ummmm if I didn't need to integrate, I'd write my own email client gui and drop support for SMTP, POP and IMAP and invent a protocol and convention that didn't require letting unauthenticated users essentially write files to your storage via an unsecured text based protocol that doesn't support compression. Then I could email myself and family members that humored me :-). In short a mail sever is integration incarnate.

Honestly what the project needs most right now is more of my time and a few more people. Open source projects are such that (as Scott so coyly pointed out) when the "vision holder" or project lead or whatever is away...the energy bleeds out. Unfortunately, my job and 9-month old doesn't let me spend as much time as I'd like (This year I spent over 50% of my time on the road), but I keep plugging away a little at a time and eventually the ball starts rolling. Patience Iago..patience.

Anyhow, while this feedback was helpful (if only to help me realize what is and isn't clear and what is plainly obvious) and I appreciate it I don't really want a whole lot more of the same. From this point I mostly don't want "justify yourself" style feedback as it takes too much time to do. Simply because I want to spend all the time that I'm not on the road working with customers, working with contributors and early adopters and writing code.

For those who are interested in contributing, I have tasks which you can complete to help "dive in". For those who think this might fit their needs and are willing to work with me, I can offer some of my time and effort in exchange for yours. Hows that? Its not quite "Blood sweat and tears," but it will have to do.

What's the complete Java class name of XmlDocument you use (package name+java class name)? I ask this because I haven't seen this class before and maybe that's the problem... If it's from an external lib, is it correctly deployed within your app or in the server/lib dir?