[ http://issues.apache.org/jira/browse/JAMES-461?page=all ]
Joachim Draeger updated JAMES-461:
----------------------------------
Attachment: UIDPlusFolderMailRepository1.zip
This is my proposal for the Maildir access in James.
For better traceability i have extendet Alexander's and Norman's efforts.
I think it's the right approach to access Maildir through the existing
implementation (javamaildir) and if needed contribute back to it.
By the way, Javamail would be a sufficient backend for a imap, one of the most
missed features in James.
I have made some progress getting the existing imap code to run that way, more
to it later.
My solution to the "James message key to Javamail message" problem depends on
the UID capabilities of Javamail and Javamaildir. That is managed by the
UIDFolder
http://java.sun.com/products/javamail/javadocs/javax/mail/UIDFolder.html
interface which is implemented by MaildirFolder. Unfortunately Javamail has
imho a few design deficiencies. You cannot determine which uid a stored message
is assigned. The IMAPFolder has such methods:
http://java.sun.com/products/javamail/javadocs/com/sun/mail/imap/IMAPFolder.html#appendUIDMessages(javax.mail.Message[])
Why the didn't they encapsulate that important functionality in an extra
interface?
I wrote a patch for javamaildir-0.6.2 (just a few lines) to implement that
imaginary interface (UIDPlusFolder) and a MailRepository implementation which
should work with any Javamail store which Folder implements that UIDPlusFolder
interface.
Imo at the moment there is no way to implement this in pure Javamail. Maybe it
is possible to implement an universal Javamail store adapter for James
depending on MD5 sums etc, but that would cost the biggest Maildir advantage:
speed.
I guess it is no problem to ask to include that few new methods in javamaildir,
which allow getting UIDs for added messages.
Asking for including UIDPlusFolder in Javamail is an attempt worth, but will
surely take years.
Without common interface there are these ugly licensing problems and
dependencies again. But we shouldn't get slow down by that. In a worst case
needed methods could be called via reflection. (i hate the word impossible)
Maven2 could maybe make things easier, too.
What do you think, could this be an solution to fulfill the James MailStore
contract?
Some notes for running the code:
* The code is some kind of "proof-of-concept" and not really testet. (messages
are stored and loaded, log looks good)
* I run it in a test enviroment using trunk r399103 (it should run with
newer/older versions too)
* It depends on javamail-1.4.0.
* The java-maildir-0.6.2-UIDPlusFolder.patch has to be applied to the archive
from http://devel.priocom.com/~zhukov/javamaildir/ the resulting jar is needed
to compile UIDPlusFolderMailRepository because of the UIDPlusFolder interface
(I can send you a copy of the resulting jar by private email, just ask)
Joachim Draeger <jd at joachim-draeger.de>
Cologne, Germany, 2006-05-16
> Maildir support
> ---------------
>
> Key: JAMES-461
> URL: http://issues.apache.org/jira/browse/JAMES-461
> Project: James
> Type: New Feature
> Components: MailStore & MailRepository
> Reporter: Norman Maurer
> Fix For: 2.4.0
> Attachments: JavamailStoreMailRepository.java, MaildirMailRepository.java,
> MaildirMailRepository.java, UIDPlusFolderMailRepository1.zip
>
> Add Maildir support..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
