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" /> Back to Eric's Home Page Up to Site Map -$Date: 2003/10/10 10:55:46 $ +$Date: 2004/01/13 03:21:41 $ @@ -83,6 +83,29 @@ failed" (leaving the message on the server, not putting it into found. (This is so you don't lose mail if you configure the wrong envelope header.)

+

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.

Back to Eric's Home Page Up to Site Map -$Date: 2003/10/10 10:55:46 $ +$Date: 2004/01/13 03:21:41 $