From 6798c96d68aa98bfd7187805aaa7b3a72eb76415 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Tue, 13 Jan 2004 03:21:41 +0000 Subject: Fix patch for Sunil Shetye's POP3 tweaks. svn path=/trunk/; revision=3871 --- todo.html | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) (limited to 'todo.html') 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 $ -- cgit v1.2.3