james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Draeger ...@joachim-draeger.de>
Subject Re: IMAP development
Date Wed, 04 Oct 2006 20:22:07 GMT
Hi Bernd,

Am Dienstag, den 03.10.2006, 13:34 +0200 schrieb Bernd Fondermann:

> as far as I understand, we need to alter the way we see/handle
> repositories for getting IMAP to work before doing IMAP itself.

Well, James IMAP code is running. It was runnable all the time sleeping
in the archives. The only problem was the missing backend. Development
and testing is hard with an in-memory-only solution.

> while I see there has been some discussion about this mixed in here,
> what is the current architectural target for this?
> currently, I am having problems to determine our roadmap concerning
> this. (did I miss something?)

It's like every time at the James project. A proposal is done, some
discussion raises up. If a "religious" architecture topic is hit like
"too much protocol dependent" there is a lot of discussion for a short
time. 
The problem is discussion hibernates without a result. 

> from my view, it would be important for an user's mail repository to
> be accessible through POP3 (inbox) and IMAP (all mailboxes) at the
> same time. repositories should not be protocol aware.

SMTP is quite important, too. ;-) POP3 and SMTP/delivery use only a
small subset of the IMAP requirements to a mailbox. 
So if you would design an API 100% IMAP dependent and be blind for the
other protocols it probably would not be a problem, you could use it via
a pop3 server anyway.
POP3 and SMTP requirements are simple.
I really can't imagine how the API could be designed that nobody would
say "oh, this looks a bit IMAP oriented, doesn't it?"

Currently in my JDBC/Torque implementation, I do it like I did for the
Imap-JavaMail-backend: provide a wrapper to allow access for all James
by a MailRepository implementation.
Of course sooner or later API should accessed directly. 

> we should extend/fix/refactor or repository architecture first, with
> IMAP in mind of course.

What IMO could be done now is deprecating MailRepository and switching
to MessageRepository with repository generated keys and no locks. A
second step could be putting the mailbox access into a session.
Apart from that we should IMHO start from scratch. IMHO the current
MailRepository implementations are no suitable to extend and refactor
them until they fulfill all IMAP requirements. In my eyes their approach is to different from
the imap requirements.

> this does not neccessarily mean we have no IMAP development going on
> in parallel. but it should not drive the repository restructuring.

Well, I guess that 80% of the API will be used by IMAP server only. 
I do not agree we should design the repository completely independent
from the imap development.
It doesn't help us if we do the design only with the theoretical
knowledge of imap requirements. When it is finished we would realize
that it's use in the IMAP server is inconvenient and cumbersomely.

To make it clear: Of course the API should be for general use.
Subfolders will be certainly accessed by Mailets etc., too.
Maybe, e.g. a webmailer uses the API too access repository directly.
Another goal is to make a Javamail-wrapper possible.
It should be convenient usable by all our protocols and needs.

And I fear If IMAP development does not drive repository restructuring
we'll NEVER get a result. IMO we need an agile and pragmatic approach.  

-------------

A quick status of http://issues.apache.org/jira/browse/JAMES-502:

Because discussion of my API proposal published as 
repository-proposal-3.zip at JIRA and on my website
http://www.joachim-draeger.de/JamesImap/
hibernated, I decided to start a prototype implementation which uses
JDBC/Torque with MySQL or Derby, under the working title MailboxManager.
Then I refactored the IMAP code to use the new API.  

Everything works quite well at the moment. I have unit tests for all
basic operations.

I just did the integration with current James trunk.
I did it completely without changing current James code. Just putting,
some jars into SAR-INF/lib and modifying assembly.xml.
I soon publish it at JIRA, when I find the time to do the packaging with
some documentation. (It always costs a lot of time so if you want to be up-to-date look at
my svn)
For the impatient: 
http://svn.joachim-draeger.de/repos/james/imap/
http://svn.joachim-draeger.de/repos/james/mailboxmanager/

My ideas to the roadmap topic:

 - after publishing API with prototype running together with imap in James I hope for some
review.
 - maybe we are able to make some decisions then
 - we have to decide if/how to integrate the code 
 - for integration everything (sandbox/branch/product/trunk) is imaginable, because it does
not interfere with existing code.

Joachim







---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message