james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: IMAP development
Date Thu, 05 Oct 2006 05:58:26 GMT
Joachim Draeger schrieb:
> 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.

Wow, then we really miss something.. Thx for diggin
>> 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. 
I must agree even if i not like the statement. We need to find better ways..
>> 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. 
Thats really cool. So we not need to change anything yet and can test it 
and dedicite after that what have todo :-)

>> 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.  
I have no problem to refactor the repository. I think thats needed for 
gettin new stuff workin. I hate the sentence "Never touch a runnin 
system" :-P

> -------------
> 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

That sounds really good. And for sure we will review after see your work 


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

View raw message