Another stab at IMAP IDLE

[Nicolas Sebrecht]

On Wed, Jan 19, 2011 at 09:56:54AM -0500, Ethan Glasser-Camp wrote:
> 
> Hey,
> 
> Regarding current status: I haven't written any code since the last
> patch series I sent to the mailing list. I did spend a lot of time
> tracking down a mysterious hang that eventually seems to be related
> to a multithreading deadlock. It's sporadic so I couldn't nail down
> what exactly caused it, but it certainly might have something to do
> with imaplib2.
> 
> I think the next step is to rewrite the patch series in a more
> approachable form. Nicholas suggested that we not go to too much
> effort to preserve the form of the commits as they were originally
> written, especially the commit messages, so I was figuring to have
> commits for:
> 
> - introducing the newest imaplib2 as a file, but not using it.
> - switching over to it, including any semantic changes that are necessary.
> - introducing IDLE functionality based on the timer hack originally
> implemented by James Bunton in
> http://delx.net.au/blog/2009/02/offlineimap-idle-support/ .
> 
> Plus whatever else seems necessary. I'm kind of busy for the next
> week or two, so if you wanted to beat the commit series into shape,
> that would be great.

Sounds like a good plan. I would encourage to send small steps, so I can
merge them in pu. Really, I _don't_ expect all such work done off-line.
The first step is the very easy task to introduce the feature and could
be merged soon.

> Since imaplib2 was dropped due to reliability concerns, it seems
> pretty important that we not cause any horrible crashes or hangs in
> switching over to imaplib2. I'd love to have more testers running
> the version of offlineimap that supports IDLE, whether they enable
> it or not.

Yes. I'm definetly more likely to merge such feature if it's optional
and marked as EXPERIMENTAL. The good news is that others could test it
and help on it easily.

>            I'm definitely seeing a sporadic hang on my extremely
> crappy Internet connection, more commonly when the connection is
> overloaded, and if anyone could reproduce that and track it down,
> that would be great.



-- 
Nicolas Sebrecht