On Wed, Jun 4, 2008 at 2:44 PM, Robert Burrell Donkin < [EMAIL PROTECTED]> wrote:
> On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak <[EMAIL PROTECTED]> wrote: > > Robert Burrell Donkin pisze: > >> > >> On 6/4/08, Ihsiak <[EMAIL PROTECTED]> wrote: > >>> > >>> Hello > >> > >> Hi > >> > >>> I am part of a team that works on integrating James with webbased > >>> mailing solution. So far, we have sucessfully developed integration for > >>> smtp and pop3, and now we are going to work on IMAP. I know that > current > >>> IMAP is not production ready - yet, so we want to work closely with you > >>> and make it better (for you) and usefull (for us). If we get > permission, > >>> therewill be probably 2 persons available for about 2-3 months for that > >>> project. But before we get to that I need to know what's current stare > >>> of IMAP code, and what areas requies work. Can anyone describe it to > me? > >> > >> There are currently two IMAP implementations on trunk. One has a > >> straightforward design and is currently unmaintained. The second is an > >> experimental rewrite. This code is under active development but is > >> difficult to work with (my interest is in advanced high performance > >> mail architectures and it's an in-place rewrite since I use it for my > >> mail). > >> > >> The main implementation is incomplete, buggy and leaks memory. The new > >> implementation works ok with the clients I use and is very close to > >> being feature complete. But the original should be fixable by > >> cross-porting. > >> Which version interests you? > > > > Definitely the second one (we don't want to duplicate integration work, > and > > do "waste" bug fixing on the old code, and then on the new one). > > good. i'll talk only the second from now on. > > > We should be able to donate two persons to work on that project - can you > > estimate how long it would take to complete "feature complete" version > > IMAP (as a specification) is interesting :-/ > > 4rev1 is specified by RFC2060 and again in RFC3501. the major > difference is that STARTTLS is not supported by RFC2060 but is > mandated by RFC3501. AIUI newish clients all use RFC3501, ancient > clients use RFC3501. IMAPS works but STARTTLS is to be implemented. > > STARTTLS should be straight forward but ideally want to push generic > support into the JAMES socket handling layer. any volunteers? > A year ago I've made a mina based IMAPS/IMAP module, for the old, straightforward design. If there is some interest to merge, I can rework it, for the more difficult design - if there is no plan to simpify/redesign that :) Currently I dont know what were my greatest concern with it. STARTTLS support is documented in the mina site, so I doesn't have to be too difficult. You can look into at http://code.google.com/p/james-imap-storage/source/browse/trunk/imap-mina/ BR, Zsombor > everything else is just about feature complete but with some areas of > buggy code which are yet to be rewritten (mainly in FETCH and APPEND). > the biggest remaining effort is going to be proving the implementation > works. this requires improving the functional test suite (and fixing > all bugs found), in particular by simulating a variety of clients. > > but feature complete is a way from being production ready. the current > backend needs a complete rewrite, for example. > > IMAP also has quite a number of additional RFCs which define extra features > Especially if you want to target limited devices, smartphones/pdas. BR, Zsombor
