What I'd really like it if you got involved in current initiatives before starting your own so that you first actually become familar with what is here and get used to working with the people HERE now. Otherwise you just become kind of a growth and don't get incorporated into the people side of the projects. I've done this a few times. If you start on the outside in we'll loose you in the end.
Now to the issue at hand.
There is no need for a private intiative. Its not like I'm STOPPING you. You only need agreement from me if you want it synched into the project plan or release schedule. I'd love it if you wrote a maillistener. However, it will won't hold up a release the way a core initiative like hibernate mailboxes, security, etc will. If you prove to me through code not dialect that it is a good approach then I've been known to change my mind (though you aren't addressing a very important audience for JBMS but I don't mind because no one HAS to use your mail listener). One day when we have more people who have been here longer I'll turn this into a more democratic system (voting and all), but its not time yet.
However there is a MASSIVE poltio-technical issue that you'll have to fight out on the JAMES mail list. I'm not going to tie us to JAMES's release plan (I'd have to be an idiot to do so). The Mailet API is part of James and is a bit too tightly coupled in places. Ideally you'd need the mailet api to be a seperate project with its own release schedule if you want to have any more than brittle support for it. I don't have time anymore for the long protracted political arguments to make this happen. If you have patience for that kind of thing, go for it. (You'll need a POC first to prove to them you're serious)
In truth, I think you're going to learn that open source projects that inhabit the same space are just as competitive as prprietary software products that inhabit the same space.
Again, I'd rather you start on something that is critical to the project right now, and come back to your own private initiatives. Help us get out M3 first, learn more about JBMS. You didn't even know about mail listeners before you posted your first "revolutionary" email. That's what I want to fix first. I can lead you to tasks as can Dawie and Mike.
Thank you for your reply.
I didn't read everything, and it's been a long while since I looked at the mail stuff, so I don't know if this is practical. But how about a JBoss Mail mail listener that acts as a "container" for maillets written to the James API?
That was along the lines of what I was thinking.
The folks over at the James project have written so many useful matchers, I thought it would be really useful to be able to use what has already been written. For instance, one of the latest ones I saw was an anti-virus scanning Matcher using the open source ClamAV. I recall there being anti-spam Matchers, blacklisted IP checkers, etc.
Combined with reasonable documentation and a whole other open source project using the Mailet API and it seemed natural to consider adoption of the Mailet API for mail processing. I just didn't know if someone had definitely shown that the API was flawed in some way. If not, it wasn't clear why it wasn't an immediate choice of mail processing APIs for JBoss Mail Services.
Thanks for your reply.
Just FYI, I went down this road and started discussing it with the JAMES people. It became really clear that the existing mailets are tied to JAMES/Avalon and that there wasn't a great deal of interest in making a really portable version of the mailet spec. Without standards which attack database bindings (no get connection), persistence, etc and at least a preexisting wide consensus at JAMES that portability is goal #1 of mailets, its just not worth my time. Building such a consensus would take months or years of discussion. I'd rather write code.