Re: nnimap 0.3.24

[Simon Josefsson <jas@pdc.kth.se>]

Seth Alves <alves@hungry.com> writes:

> > If you have two server connections open and receive a mail into a
> > mailbox, the first client who does a LIST will get the \Marked (or at
> > least not the \Unmarked) flag but after this, the second client will
> > get \Unmarked flags on this group since nothing "has changed since the
> > mailbox was selected".  The concept of \Marked/\Unmarked flags feel
> > extremely single-client, single-connection oriented to me.
> 
> Yeah -- I think it is.  Are there plans to make nnimap open multiple
> connections to a server?  

Yes.

I'm not sure what the gains of opening one connection for each mailbox
which seem to be a common practice are, but opening additional
connections to the server for big article fetch(es) or a big header
fetches will be very useful -- if the user interrupts a big fetch,
nnimap will be able to continue to operate without waiting for the big
fetch to finish.

(Naturally, nnimap should wait for a interrupted fetch to finish and
then issue a LOGOUT, but this can be handled asynchronous.)

For doing asynchronous pre-fetches of articles, we should open another
connection to the server and do BODY.PEEK on the articles Gnus tells
us to fetch. If you read NNTP groups with Gnus today and use
asynchronous prefetching, you already know that asynch fetches are
nice.

Also, when Lyndon Nerenberg's "You've got mail" protocol is published
and implemented in some servers we could use it to look for new mail
asynchronous and update Gnus's group list automagically (if this is
possible). I think this would be very cool -- you sit and watch your
*Group* buffer and as new mail arrives, the unread counter increases.

> Could the behavior of finding new mail with the list command be a
> configurable option?

I'm not sure what you want to do instead, but I'm open to suggestions
and if you write the code I'll put it in (unless it seriously breaks
something).