[PATCH] Avoid Fatal error: Word too long from Cyrus IMAP servers by chunking fetch.

Sebastian Spaeth sebastian at sspaeth.de
Fri Jan 21 08:54:39 GMT 2011


On Thu, 20 Jan 2011 18:06:03 -0500, "Edward Z. Yang" <ezyang at MIT.EDU> wrote:
> That is a good point.  It is mitigated by the fact that this code
> is only exercised when you have maxage set, which bounds the number
> of messages you may pull (and paradoxically hugely increases the size of
> your query.)  It is too bad there is no SEARCH-AND-FETCH command.
> This is actually probably why you've never seen this error :-)

I don't have maxage set, so that's why I might never have seen
that. That having said, I do fetch all UIDs and FLAGs for all folders in
the regular case from the server as well, so it is possible for sane
mail servers (if mail server and sane goes together at all).

WIth maxage, the number of fetched UIDs should be rather limited
(hopefully), so you might be right that it doesn't harm too much.
 
> Nevertheless, the number could probably be a lot bigger than 50,
> and doing a test on the original query shouldn't be that expensive
> and is probably the right thing to do, albeit more complex code-wise.

I'd rather punish users of buggy servers than those of sane ones :-).
 
> > I don't think we should perform the least common denominator actions by
> > default. If we do that for all server quirks, offlineimap would soon
> > become unusable.
> 
> Doesn't OfflineIMAP already have lots of workarounds for servers? ;-)
> I'm personally very displeased with the X-OfflineIMAP header that is
> added :-P

I am sure we have workarounds for servers, however I would be very sad
if we added many that punished users of sane servers severely. There is
a difference between checking if a server replied with several "EXISTS"
messages and between fetching mail info in tiny bits for all users :-).

That having said, if we tested performance and find that it is an ok patch,
go for it. I just don't want to see it merged without a
discussion/evaluation of its potential side-effects.


x-offlineimap: I know that there has been discussion about some
X-OfflineIMAP header previously, but I don't know what it is for or why
we insert it. I would actually object pretty loudly against us
*modifying* the mails that we sync in any way. Perhaps now is the time
to start a new thread looking at that header. Is it _really_ needed? It
is an IMAP<->IMAP thing, right?

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110121/c88b6811/attachment-0001.sig>


More information about the OfflineIMAP-project mailing list