<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div id="yiv299963617"><div style="color:#000;background-color:#fff;font-family:times new roman, new york, times, serif;font-size:12pt;">>On Mon, 27 Jun 2011 02:22:17 -0700 (PDT), chris coleman wrote:<br><div class="yiv299963617yui_3_2_0_2_130922818292952" id="yiv299963617yui_3_2_0_2_130922818292954" style="font-family:times new roman, new york, times, serif;font-size:12pt;"><div id="yiv299963617yui_3_2_0_2_130922818292986" class="yiv299963617yui_3_2_0_2_130922818292957" style="font-family:times new roman, new york, times, serif;font-size:12pt;">>> @Sebastian: What's your thoughts on fixing imaplib2 or offlineimap, so<br>>> they respond properly when an untagged CAPABILITIES response arrives<br>>> at any time.<br>><br>>Piers, the imaplib2 maintainer (although Nicolas is basically taking<br>>over ;-))
has indicated that we should be doing that from offlineimap, and<br>>I'll send a patch to that regard. OfflineImap already makes use of the<br>>APPENDUID reply from Gmail,
so there will no change in behavior.<br>><br>>> Just in case, one day a user gets an IMAP server that changes the capabilities. Imagine a cluster scenario, the 1st IMAP server goes down, the load balancer switches over to the 2nd IMAP server, which announces different capabilities.<br>><br>>Well, the suggested fix (requery capabilities after login) won't help<br>>that scenario as your imagined switchover could happen at any point in<br>>time and not just pre/post login.<br>><br>>Sebastian<br><br>@Sebastian : Wouldn't a better way to solve this bug (caused by failing to process legitimate, untagged messages from the IMAP server), and solve it (any any other unforeseen bugs) for any future scenario: for offlineimap to delay querying imaplib2 for UIDPLUS capability until JUST BEFORE the various places in the offlineimap code where a UID might be received as part of a response. Then, depending on the response, the code
would branch between different code paths: the UID case and the no-UID case.<br><br>It sounds like this solution is possible without any upgrade to imaplib2, which updates its cached CAPABILITIES array every time
it receives new capabilities from the imap server, from what you've said.<br><br>The bigger point is: it seems this bug was caused by offlineimap not fully complying to the IMAP4 client spec according to the requirement to accept and process any response from the server at any time.<br><br>Taking a step back, why shouldn't offlineimap/imaplib2 follow the IMAP spec completely? Obviously it's not an easy client spec to implement 100%, because the client must behave more like a hybrid client/server. A simple dumb client (such as POP3) can be very simple, and way easier to implement, because it just makes requests, and receives only deterministic answers stemming directly from those requests. <br><br>It's a much greater challenge to make offlineimap as utterly bulletproof as fetchmail/pop3.<br><br>Chris<br><span></span></div></div></div></div></div></body></html>