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: Imap status
Date Wed, 04 Jun 2008 16:51:43 GMT
On Wed, Jun 4, 2008 at 2:25 PM, Zsombor <gzsombor@gmail.com> wrote:
> On Wed, Jun 4, 2008 at 2:44 PM, Robert Burrell Donkin <
> robertburrelldonkin@gmail.com> wrote:
>
>> On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak <ihsiak@gmail.com> wrote:
>> > Robert Burrell Donkin pisze:
>> >>
>> >> On 6/4/08, Ihsiak <ihsiak@gmail.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message