Harmeet Bedi wrote:
Peter was already working on this I think... it would be great to execute on it and get a stable point release out there.We should have a plan and release manager for the next major release.
I'm very much in favor of leveraging standard APIs, but I'm not sure JNDI can give us the features we need. I think JNDI could be useful for the account authentication layer I mentioned a few days ago. But in terms of mailbox management and mail queues/stores, I'm doubtful.Here are some ideas. - Have a single, standard repository API. Noel, others have mentioned JNDI.
This could be part of mailet 2.0, but I don't know if they need to be necessarily... they could just be a few standard APIs as part of James.
Yes, I'd love that. We'd need to figure out what extra requirements NNTP would place on the existing repository APIs.- Move all protocols including NNTP to use that repository API.
- IMAP Server support.
Would be nice, but it's always a hard one.
Seems like this is progressing nicely. Woohoo! I'm a big XP nut, and think the more testing we can do, the easier it will be to develop.- Test Bed to check RFC compliance, performance and stability.
I'd like to understand what people mean by this. Are you talking about using Outlook to communicate with James as if it was Exchange, because that's done with a MAPI interface. In fact you can buy custom MAPI services that will let you treat any IMAP server (that has full ACL features) to pretend to be an Exchange server. Or is this handling the schedule request messages? I think either of these could be a good subproject in James, but the later would require you to build a full calendar server.- Experimental MS Exchange Protocol Support.
I've been as guilty as anybody of getting frustrated with certain parts of Avalon, and then condemning the whole lot. There's plenty of good there, and I think there are parts where we need to take ownership of the implementations because they are so key to James. We've relied probably way too long on the file stream implementation for the file message store, and the thread management/object pooling/connection pooling and other pieces might be better to build in the James codebase. As Steve just added, the design gives us the liberty to choose, and we (I) should do a better job appreciating that.- Move away from Avalon/Phoenix. There has been some talk on this topic. We could keep the framework part and not use Phoenix if this is a sensible goal.
Just speaking philosophically (and not about any particular decision), what do people think of this approach: when we hit a piece of the Avalon codebase (framework, excalibur, what-have-you) that we're unhappy with, then we make a copy of it, possibly even repackage it, add it to James, and make the code work for our needs. Often we will know a small piece is not working, but may not know the perfect solution until we use it in James for a while (a few test runs, maybe a few months). I think we would benefit by not getting (feeling) stuck waiting for an Avalon release, and the Avalon projects would benefit with more people building components. This can be done as healthy competition, and if we ultimately figure a better way to build a component, we can certainly pass it back to Avalon's codebase.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
