X-Git-Url: http://pileus.org/git/?a=blobdiff_plain;f=todo.html;fp=todo.html;h=6060ecdcf37ebdf0cf86e5662a34444757124872;hb=6798c96d68aa98bfd7187805aaa7b3a72eb76415;hp=0ce5014adf101a1fa58429a60c40ba7973c9130d;hpb=96c464a8399b5ba2df510e7f0726b216eeefe722;p=~andy%2Ffetchmail diff --git a/todo.html b/todo.html index 0ce5014a..6060ecdc 100644 --- a/todo.html +++ b/todo.html @@ -19,7 +19,7 @@ content="Known bugs and to-do items in fetchmail" />
Matthias Andree writes:
+ +++ +NOTE that the current code need optimization, if I have +unseen articles 3 and 47, fetchmail will happily request LIST for +articles 3...47 rather than just 3 and 47. In cases where the message +numbers are far apart, this involves considerable overhead - which +could be alleviated by pipelining the list commands, which needs +either asynchronous reading while sending the commands, or knowing the +send buffer, to avoid deadlocks. Unfortunately, I don't have the time +to delve deeper into the code and look around.
+ +Note that such a pipelining function would be of universal use, so it +should not be in pop3.c or something. I'd think the best approach is to +call a "sender" function with the command and a callback, and the sender +will call the receiver when the send buffer is full and call the +callback function for each reply received.
+ +See the ESMTP PIPELINING RFC for details on the deadlock avoidance +requirements.
+
The Debian bug-tracking page for fetchmail lists other bug @@ -93,7 +116,7 @@ reports.