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: Are there nightly builds for http://svn.apache.org/repos/asf/james/protocols/imap/trunk?
Date Wed, 18 Mar 2009 10:23:51 GMT
On Tue, Mar 17, 2009 at 6:45 PM, Martin.Bergljung
<Martin.Bergljung@opsera.com> wrote:
> Hi,
> Regarding the build: I can get the /james/server/trunk and build it
> without any problem.
>                     Building /james/protocols/imap/trunk does not work
> with ant. Missing some macros,
>                     added them but got more errors, libs missing.
>                     So just loaded everything into IDEA and build my
> own jar.

that's odd :-/

i built it several times yesterday without problem. if you could open
up a JIRA and attach a stack trace of the failure, that'd be great.

> I have now managed to swap out the Old IMAP protocol implementation for
> this new one in the Product I am developing.
> A have tested it in Outlook, Thunderbird, and Lotus Notes. Notes has a
> bit to go I think as it fetches partially instead of Full Content as
> Outlook and Thunderbird. But probably something in my Result builder I
> need to fix.

IMAP is a complete PITA. thunderbird doesn't work to my satisfaction
but since evolution has now broken IMAP (after the upgrade to SQLLite,
transaction bugs for multi mailboxes have only been fixed in the
unstable trunk) i'm now working on that.

to be honest, though i believe IMAP to be reasonably compliant with
the specification (the functional tests have good coverage of the
basics), i only really consider it alpha quality. in particular, the
torque backend needs to be replaced. developers have reported
successes forking the code for their own purposes but if the APIs are
still evolving so it's best to play close attention. if it's possible
for you to contribute to the development of james then it might be in
your best interests to do so.

> However, as my backend is Alfresco

(i'd be interested in collaborating in if this is an open source project)

if you're porting to a new backend, once the functional tests run then
you'll have basic IMAP compatibility

> and hierarchy delimiter is / I had to
> just change that directly in ImapConstants
> as the request for hierarchy delimiter is kept entirely in IMAP layer
> (i.e. A1 LIST "" ""). Or is there another way to do that.

this should really be configurable but probably only at assembly time

i've raised https://issues.apache.org/jira/browse/IMAP-70. hopefully,
someone will get to it sometime soon.

> Further on, when using the previous IMAP implementation I was keeping a
> ThreadLocal object that I called AlfrescoPerson with a couple of
> properties for logged on user. With this new implementation I will have
> to change that as the threads
> does not stick to an IMAP session, or I am doing something wrong, but
> better scaling anyway...

yes, the threads are pooled

if it's just a backend attribute then create a MailboxSession
implementation that stores the addition information (the API is still
fluid so if you have any design ideas or requests, feel free to post
them to the list or raise a JIRA)

if it's an attribute that processors are going to be need to
understand then use ImapSession getAttribute/setAttribute

> Also, I do not pass around the user namespace and username for the
> mailboxes (e.g. #mail.martin) but instead rely on
> being able to get to the AlfrescoPerson object for logged on user (i
> strip off the #mail.martin in the MailboxManager.resolve method -
> although this is not completely consistent as I still get the
> #mail.martin passed to for example MailboxManager.search).
> I deal with mailboxes such as "/Company Home", "/Company
> Home/Marketing", "/Company Home/User Homes/mbergljung" etc and the
> permission system in Alfresco controls if the user has access to them or
> not. So would have been good if I could have used the ImapSession and
> set and attribute there.
> So the MailboxManager and Mailbox interface methods could take the
> ImapSession (which includes any MailboxSession)
> and then you could just set any attributes you wanted and have them
> accessible whenever you wanted.

this separation is a consequence of legacy architecture decisions

i've created a JIRA (https://issues.apache.org/jira/browse/IMAP-71)
with some thoughts. please take a look.

> Also noticed that some calls such as SELECT generates more processing
> then necessary, in the following select call each response such as
> recent and total number of messages generates a lot of
> mailboxManager.getMailbox, only one call should be necessary, does it
> have to do with:
>        // TODO: compact this into a single API call for meta-data about
> the
>        // repository
>        flags(responder);
>        exists(responder, mailbox, mailboxSession);
>        recent(responder, selected);
>        uidValidity(responder, mailbox, mailboxSession);
>        unseen(responder, mailbox, mailboxSession, selected);
>        permanentFlags(responder, mailbox);
>        taggedOk(responder, tag, command, mailbox);
> In the AbstractSelectionProcessor?

i think this need more thought and discussion.

IMAP is an absolutely beastly protocol to use with a modern platform.
at first glance, it might seem to be better to map every protocol
command into a direct, specific data access call. separation of the
processor layer is intended to allow anyone who wants to go down that
route to just rip out the mailbox approach to data access.


1 the justification for a separate mailbox layer for data access is
that it would present a more generally useful API. i've always been a
little sceptic about whether this would be possible but - so far -
i've been able to get adequate performance whist retaining it.
2 from a throughput perspective, when SEDA is switch on, the repeated
data access calls allow writing to start in parrellel to the socket.
in this case, probably single call would be better for many data
access layer. it's a hard call, because which is better depends on the
nature of the data store.

my thinking on transactions is that a call back interface would have
advantages but in any case,  calls would be need to control the
transaction. perhaps an elegant solution would be to allow a hint to
be passed to the mailbox to allow more efficient use of caching.


> I will continue testing and fixing so hopefully I can get to a point
> where I can continue with the new IMAP protocol implementation.

great :-)

- robert

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

View raw message