On Wed, Jun 4, 2008 at 2:25 PM, Zsombor <[EMAIL PROTECTED]> wrote: > 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 :)
hoped you might say that :-) but i was planning to wait to ask until we're ready to review and rework the data access and socket APIs. before we turn to that, i think that functional compatibility test needs to be completed. this will allow safer refactoring without regression. that's pretty close now. > Currently I dont > know what were my greatest concern with it. the old version crashes some older versions of Mail, Thunderbird and Evolution > STARTTLS support is documented > in the mina site, so I doesn't have to be too difficult. i agree that STARTTLS should be straightforward. i thin k that the switching needs to be socket API (eg mina). - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
