Richard Heyes [2004-01-31 20:54 UTC] A combined mail access structure of classes with a singular frontend API, and multiple backends (eg. Net_IMAP, Net_POP3, C-Client support etc) would be great for PEAR.
Bertrand Mansion [2004-02-01 10:51 UTC] I don't like the class with your recent additions related to output (called "Bells and Whistles" in your comments). Those methods are View related and output html. They don't belong here and they just make the class more bloated.
Same thing for the forum stuff. Just get rid of it, if people want to have this feature, all they need is the raw mail body and a static function to parse that content in the format they want. Really this just adds bloat to a class that needs to be as light as possible.
Also, I don't see the point to call your methods imapSomething. Just get rid of the imap prefix and we might be able to later have a Mail_POP3 class with the same API.
And again, you have instance vars called ccPersonal etc., which might not be set. Are you going to try to match every possible header lines to instance vars ? That's the bad way. Just have a header instance var (array) and fill it with clean header values. Then add a few accessor methods for common header content that needs cleanup (ie. getTo(), getFrom(), getSubject()...).
Vitaliy N. Kravchenko [2004-02-02 16:54 UTC] More interesting implementation of IMAP protocol in native, by using sockets().
Like in SquirellMail php-web-based email system.
because imap_* functions not always work correctly with various IMAP servers. And required imap-php4-module compiled in php...
Thanks.
P.S. Sorry for my english.
|
