On 6/14/07, Norman <[EMAIL PROTECTED]> wrote:
Hi Steven,
hi steven your timing is impeccable :-) nice to see you are intressted in help out. I think Robert will tell you
as soon as he see this mail. He is the one which work activly on IMAP at the moment.
+1 i was framing a initial reply when norman beat me to it :-)
I would like to help developing the IMAP module.
great Can I know which part I can assist on current development? anything and everything e.g. some IMAP extensions? if that's your interest, then yes this is a good time to outline the refactoring i've been doing on the branch: i'm not sure that the direction may have always been clear to everyone but it should be easier to see now that it's nearly done. i'll also outline future directions that my interest is likely to take me. first, i'll try to give a realistic assessment of the current state of the code base. there's a lot to be done but hopefully this won't put you off: i'm confident now that it's all fixable within a reasonable timescale. JAMES has been serving my local email over IMAP now for a number of months. i use SIEVE to filter the large volumes of mail i receive into mailboxes. SIEVE works reasonably well. JSieve is excellent. i suspect that the mailet has some obscure issues (about 0.5% of my mail is malfiltered but jSieve executes correctly when tested with the mail input) which i have yet to track down. the IMAP implementation in trunk is incomplete. there are a small number of commands which are missing implementations and some implementations are incomplete. there is one particular bug that is positively dangerous and hard crashes some email clients. i have a local workaround (aka hack) but this is not specification compliant and has other issues. i also strongly suspect that a number of the implementations do not comply with the specification for all use cases. the current implementation is also *very* slow. the only mailbox implementation is provided by torque and suffers from major performance issues. the mailbox API is not tuned for IMAP and results in overly chatty database access. however, i've been running profiles for many months now and though i'm not convinced that this design will ever give sparkling performance, there are a number of major improvements which could be made relatively easily. it also suffers from memory issues on a small number of 1.5 JVMs but runs well for me under java 6 the refactoring i've been doing on the branch has been to create four separate, loosely coupled components: server, encoder, decoder and processor. each can be tested independently and each is capable of independent implementations. the only component coupled to the mailbox API is the base processor implementation. the approach to the design of each base component is hopefully now more easily extensible. IMHO it is a mistake to insist that every storage solution supports every possible extension. messages are used to pass information between the components. i'm in the process of moving towards a closer domain model of the specification. these messages should model the concepts used in the specification. i think that this mapping should make it easier to comprehend the relationship between the code and the specification. there are plenty of independent areas where work needs to be done (i'll pick out a few below). my suggestion would be to pick an area that interests you. either just start contributing patches through JIRA ( https://issues.apache.org/jira/browse/JAMES) or post on list and we'll give you ideas and opinions. if you haven't contribtued to apache before, please read http://www.apache.org/foundation/how-it-works.html (and browse the site including http://www.apache.org/dev/). please read http://james.apache.org/guidelines.html, http://james.apache.org/contribute.html and http://james.apache.org/code-standards.html. consider submitting a CLA. please ensure that all contributions are original works (stuff you wrote yourself for apache) and have the license header. you retain the original copyright for the patch (but you agree to grant apache a liberal license). apache uses open development. we try to keep as much as possible on list. this is where development happens. feel free to post questions, answers, comments, ideas, criticisms (of ideas, not people and constructive please) to the list. we're an international bunch here at JAMES so code or UML is often more effective than long explanations. anyway, onto development topics my main personal interest is really in developing SEDA IMAP backed by a JCR. this will probably mean a new MINA based implementation of the server component and a new processor component. if either of these interest you too, feel free to pick one. extensions ------------- pick one :-) torque -------- the torque mailbox implementation is slow. the mailbox API is general and far too chatty. the table design is inefficient with far too many joins. there are a number of big improvements which could be done relatively easily. the first area is reducing full table scans. this can be solved by indexing the tables and by removing a number of unnecessary joins. the second area is that the mailbox pre-emptively loads mail into memory too often. the third area is that UIDs are handled very inefficiently. MIME4J ---------- the show stopping bug is cause by the java mail specification. java mail is really inappropriate for server use in many ways. it needs to be replaced by MIME4J (the JAMES MIME mail parser). complete commands ------------------------- complete the base IMAP4rev1 implementation by complete missing commands functional tests ------------------ need a comprehensive functional (end-to-end) test suite for IMAP performance --------------- there are a lot of areas that could do with attention including UIDs, mailbox event handling, less chatty APIs and so on. should make a list in JIRA... or anything else that takes your fancy ;-) - robert
