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? 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 > (count us too, but keep in mind that we have to get familiar with the code > first). the developers on IMAP are volunteers and many work on multiple projects. JAMES is also into an intensive cycle of releasing components which is my personal priority ATM. so estimates and deadlines are difficult. there's also the question of what production readiness means: running live on the internet is quite different from running on a intranet protected by a firewall; serving a few dozen users is very different from serving thousands. but i think that 2 extra developers should be able to achieve a reasonably good IMAP over 2-3 months. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
