Hi Joachim,
I'm happy to read your message: it seems to me you understand the
current imap2 status better than most of the developers that approached
the problem in the last year.
I just created a "parent issue" in JIRA to track the IMAP support in James.
http://issues.apache.org/jira/browse/JAMES-502
As I wrote in the issue I'll be happy to help with the James integration
and reviewing anything that will be submitted.
Please, feel free to submit also incomplete/not working code: I think
this would be useful anyway for anyone else working or studying IMAP on
James.
I have a different idea on the steps and their priority, more tightly
coupled to the developing cycle: we should try to make it working as a
module with no changes to the rest of James, so we should make first the
necessary modularizations James needs for this to happen, then we should
create a sandbox project with the module: integrating it to James should
be only a matter of adding the james-imap jar the assembly declarations
and the config.xml stuff.
Stefano
Joachim Draeger wrote:
Hi Stefano,
Stefano Bagnara wrote:
I will try to submit soon an updated imap2 proposal (updated to build
against the current trunk), so you'll have an updated source to start
your work from!
I have already made some efforts in that direction. The main problem for
me was the in memory store because I need something to "touch" when
working with code. I guess many people feel the same and that's a reason
why there is so less success with it.
So I began to fix it to let it compile against trunk and added a, guess
what, Javamail backend. For traceability I tried to touch as few of the
existing code as possible. I wanted to clean my code a bit before
publishing it. But if people are eager I could put out what I have in
the next week, okay?
At the moment my backend is not very stable and it is only supporting a
few operations.
The existing frontend part of the Imap2 proposal looks quite
sophisticated even it is not easy to understand. But I think that is due
to the fact that Imap is a *very* complex protocol. Pop3 is breeze
against that.
I have seen a compatibility chart for the existing code that looks quite
impressive.
I suggest the following steps:
1. Implementing a backend for the existing code. For me that is
unavoidable before further steps. Javamail has everything that is needed
for that and it shouldn't be too much work. Before starting a big
discussion: I'm just talking about a wrapper for the existing
interfaces. No serious design decision for Javamail is made at this point.
2. Documentation for the existing code. Maybe some fancy UML, or just
prose. Just how it works and how components are interacting. I think it
is important to understand the existing code before making too much
changes to it.
3. Discussing the existing architecture and talk about an adequate backend.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
