<[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit
David Champion wrote: > ive.org> <[EMAIL PROTECTED]> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > In-Reply-To: <[EMAIL PROTECTED]> > X-Comment: no > User-Agent: Mutt/1.5.8i > X-Decanonizer: current version 0.2005.05.10 > for j4RMOhww016410 from localhost [127.0.0.1] > at 1117232684: Fri May 27 22:24:44 2005 [0.172s] > > * On 2005.05.27, in <[EMAIL PROTECTED]>, > * "Daniel Senie" <[EMAIL PROTECTED]> wrote: > >>yes, it'd have to happen without actually reading the mailbox. Guess a >>"last checked time" database would be needed. > > > That's actually the point of the patch. It adjusts a user's allowable > check frequency based on his or her individual usage, and remembers the > last check time for each user separately. > > The only thing in this that's not done is allowing the response message > to be configured. And that's necessary; I won't change it evenly to "No > new messages" across the board. The original proof of concept patch did > that, and our support center objected that they'd get calls from people > who got "no new messages" and then a big flood of new messages on the > next check. They *wanted* an error response. > > I'll make it a runtime option. > Thank you! I think the 'no new messages' is probably preferable if you intend to set happymail-base to a low value. There should be no big flood of mail in this case. Where rate limiting could result in larger delays for mail, then the error message is probably preferable. Making it a runtime option is perfect way to allow for both configurations of HappyMail. Ken Anderson Pacific.Net
