On Thu, Dec 09, 1999 at 03:42:09PM -0500, Tim Pierce wrote:
:
:For the record, I find "there are too many buggy POP3 servers to support
:effectively inside Mutt" a far more persuasive argument than "POP3 sucks
:and I'd rather see that it remains outside of Mutt."
If Mutt were to start supporting POP3, it only needs to understand a
subset of the commands: USER, PASS, STAT, RETR, DELE, QUIT. STAT to
find out the number of messages in the maildrop, RETR to download *all*
the messages without choice, and DELE to remove said messages. Anything
else is pushing POP3 beyond its intended design. Anyone else wanting
additional features should use IMAP. Anyone wanting IMAP-like features
by hacking POP3, tough. That's not Mutt's job. And if there are enough
buggy POP3 servers that can't even handle this limited command subset,
then Mutt should never even consider POP3 support.
:It appears that "bloat" is just a short way of saying "features I don't
:want." Maybe we could focus on the technical merits or shortcomings of
:suggestions rather than appealing to a vague sense of "bloat."
bloat == the result of creeping featurism
BTW, some people think ActiveX and Internet Explorer should be part of
the OS. Others consider it as bloat.
But back to the point at hand, there are actually two issues to debate:
- should Mutt have POP3 support?
- what kind of support, and how hard would it be to implement it?
To the former, my response is "NO". But to the latter, I've offered
some suggestions to its support. Tim, I noticed that you did not
respond to my comment about a completely separate code base that
implements POP3 (e.g. an imaginary libfetchmail.so) that other apps
(including Mutt) could use. That's the solution that I think would
benefit everyone. Tim, what is your solution? And please be specific
about the implementation, its completeness, and its robustness.
I find your lack of content disturbing. And Patrician.
--
Eugene Lee
[EMAIL PROTECTED]
