Re: Considering reverting imaplib2.py and IDLE support - need feedback

[John Goerzen <jgoerzen@xxxxxxxxxxxx>]

David Favro wrote:
> John Goerzen wrote:
> I'm all for fixing/not-creating bugs, and I have no knowledge of either
> imaplib or imaplib2, but I'd just like to say that IDLE support is in my
> mind a very important feature.

Hi David,

Thank you very much for the feedback.  I agree that IDLE is a nice
feature.  More comments below:

> I wonder why someone (Piers Lauder apparently) decided to write imaplib2
> unless the original imaplib has innate architectural limitations, which
> might indicate that imaplib2 is "the future" and the transition will
> likely be made eventually anyhow -- so perhaps efforts are better spent
> helping imaplib2 to progress or just waiting for it to improve.  Those

It appears that he wanted a multithreaded IMAP library.  There is,
however, no indication that I can see that standard imaplib will be
replaced.  As far as I'm concerned, the API of both leaves a LOT to be
desired.

> who desire more stability could continue with an older version of
> offlineimap until imaplib2 becomes a little more stable.  I'd be

That becomes a very confusing proposition.  Users normally assume that
the latest versions have the latest bugfixes and are the best ones to
run.  To say, "hey, current release is 6.1.x, but please just use 6.0.x"
is confusing.

If somebody wants to maintain a git branch with imaplib2 integrated, and
work on it until upstream gets their act together, that's fine with me
and we could certainly switch back to it later.

> interested in knowing the significant differences between imaplib and
> imaplib2.  If reverted, would the intention be for offlineimap to remain

Other than threading, I don't know; someone that knows better would have
to comment.

> without IDLE support indefinitely, or just to wait for a more stable
> version of imaplib2?  Sorry if this has already been discussed, but I
> haven't been following the list too closely of late.

That depends on contributors.  As you might know, I have been
desperately trying to spend less time on OfflineIMAP for years now :-)
Someone else wrote the existing IDLE support, so it would fall to him or
some other contributor to write (or fund) IDLE support with imaplib.py,
if it's even possible.

> Offlineimap is a great idea (for me), because it attempts to implement
> on top of IMAP something that IMAP wasn't really intended for: a truly
> distributed/replicated mail architecture.  Since it seems that the IMAP
> protocol was more intended for a centralized, always-online,
> client/server architecture, it doesn't really contain the necessary

Actually, the IMAP protocol has features in it (UIDs specifically)
intended for uses like this.  It's just that they are very rarely used
in this manner, unfortunately.  I'm not doing anything IMAP didn't
contemplate; just something that most people today don't do.

My main concern is new users: if users download OfflineIMAP, find it
crashes and hangs, they're going to leave.  Ultimately, that's bad for
the whole community.  New users mean potential future developers, and
everybody that has written code for OfflineIMAP -- including IDLE
support -- I'd wager started first as a happy user.  If it takes "in
crowd" knowledge to find a version that doesn't crash, we have a problem.

-- John