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 Idle Command
Date Fri, 17 Aug 2007 12:57:30 GMT
On 8/16/07, Paulo Sergio <pauloslf@gmail.com> wrote:
> Hi Robert,
> On 8/16/07, Robert Burrell Donkin <robertburrelldonkin@gmail.com> wrote:
> > On 8/16/07, Paulo Sergio <pauloslf@gmail.com> wrote:


> > > what would  be the right approach to do it?
> > > i probably should add imap idle to the command library, and then add a
> > > processor to handle the request,
> > > but how should i keep the connection open?
> >
> > an IMAP client creates and holds open a connection to the server
> > throughout. the problem is that the current handler uses only one
> > thread.
> >
> > > to send the notifications back to the client?
> >
> > this means moving to a SEDA based design.
> but do you think i have to switch to a SEDA architecture ?  or SEDA  would
> just be a better  option?

i don't see how IDLE could be implemented using blocking IO and a
single thread. therefore the older, JAMES handler just isn't
sophisticated enough. so, a new handler architecture would need to be

there are various ways to design these kinds of system.

the experimental IMAP stuff is aimed at an event driven architecture.
so, moving to SEDA is a relatively small amount of work.

if you prefer locking based architectures then it may be possible to
reuse the components but i recommend that you do enough up front
analysis of the protocol to ensure that the design is robust enough to

> > the medium term aim would be
> > to move to MINA and nio but in the short term, a three thread
> > implementation (input, output, processor) is a stepping stone which
> > would probably be satisfactory for IDLE. this should be relatively
> > easy to implement.
> yes i think Mina is a good choice, it seems to have a lot people working
> with it, and i've seen some good reviews about it.
> but is these just an idea or there is really a plan to implement it?

depends what you mean by a plan :-)

MINA is SEDA. it's pointless reinventing the wheel when there's
already a set of flashy alloys available.

- robert

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message