james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: IMAP Protocol implementation comments
Date Fri, 01 May 2009 17:07:55 GMT
On Fri, May 1, 2009 at 10:29 AM, Martin.Bergljung
<Martin.Bergljung@opsera.com> wrote:
> Hi,
>
>
>
> First, thanks for all the work that has been done to develop a new IMAP
> protocol implementation.
>
>
>
> I am developing an IMAP Mailbox Manager backed by Alfresco and has been
> using the old IMAP implementation since 2008-01. Last month I have
> upgraded the implementation to use the new IMAP Protocol implementation.
> It has been successful and I have done extensive testing with MS Outlook
> 2007 and Mozilla Thunderbird 2.0. Will do more testing with Lotus Notes
> 8 in the coming weeks.

great :-)

> I have some comments though, about the new implementation:

i've been looking forward to these :-)

> *         The new change to include the username in the MailboxSession
> is a good idea. Unfortunately I still have to prepend the username to
> all mailboxnames (e.g. #mail.mbergljung.INBOX/Company Home) in the
> MailboxManager.resolve method as not all methods in the MailboxManager
> takes the MailboxSession parameter. I then use the mailboxname to
> extract username in all MailboxManager methods to get to a Person object
> with more info. A couple of reasons why I need to access the username in
> all methods are:
>
> o   I need to check user permissions for the particular operation (i.e.
> does user have permission to create mailbox, does user have permission
> to update flag etc)
>
> o   I need to get to an Alfresco Person object with more user
> information such as Home folder, Locale etc
>
> o   I need the username for logging

i agree

i plan to push the final name resolution into the mailbox layer and
pass the MailboxSession into every method. would that work for you?

> *         I have to change hierarchy delimiter from '.' to '/' in
> MailboxManager, LSubProcessor, and ListProcessor. Would be good if there
> was a way for me to just tell the IMAP layer that I would like to use
> the '/' as delimiter. I know that each command response usually contains
> the hierarchy delimiter that is to be assumed but it does not cover the
> complete IMAP implementation.

i agree

my current thinking is to make the IMAP hierarchy delimiter
configurable (by injection) at assembly time (probably hanging off
some sort of configuration object)

i suspect that the most elegant way to do this would be to introduce a
MailboxName object whose path is fully parsed. the mailbox
implementation could then rebuild a suitable name for it's storage.

opinions?

> *         The EXPUNGE command does not work correctly:
>
> o   The EXPUNGE can be executed and the server side will physically
> delete all emails marked for deletion
>
> o   However, whatever is sent back to the client is not correct as it
> does not remove the emails from the UI (used to work fine in old
> implementation)
>
> o   If I click on other mailbox and then back on mailbox that had emails
> expunged they are gone (so a workaround exists for the moment)

EXPUNGE is a funny old command, specification wise. i need to take a
look into this. i've created
https://issues.apache.org/jira/browse/IMAP-78

> *         The SELECT command is too chatty at the moment I think. I get
> loads of calls to MailboxManager for the Mailbox just to put together a
> SELECT response.
>
> o   The Mailbox object is requested several times (4) when it should
> only be requested once and then you could get the values needed for the
> response

SELECT is a major PITA, and yes something needs to be done. the torque
implementation is ok speed-wise but that's probably luck. i've created
a issue https://issues.apache.org/jira/browse/IMAP-79 to track this

- robert

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