Karl Dahlke <[email protected]> writes: > 1. Access an imap server much as we access a pop3 server today.
I'd rather not do this if we can avoid it. Our SMTP implementation had undiscovered bugs for years. Remember dot-stuffing? IMAP is an even more complex protocol. > 2. Try to use a linux imap library to help us, At a glance, vmime might be promising. It's a C++ library, though. > 3. Ask the user to use a separate stand-alone program to pull > mail off an imap server and into a local mailbox file. If we do this, we'll miss the great selling point of IMAP: keeping mail in separate folders with state kept on the server. We could handle separate folders with method 3 if we added code to edbrowse to handle maildirs or multiple mailboxes. The state of messages will be lost from the server, though. I can't see a way to do option three without losing some of the advantages of IMAP. Here goes some IMAP propaganda. The nice feature of IMAP is multiple folders. I get lots and lots of email. Most of it is from mailing lists, but I also have quite a few online collaborators and friends. On my IMAP server, mail is filtered into multiple folders by criteria such as sender, mailing list ID, and so forth. The filtering is done by an external program. I have a special folder just for personal mail from Karl. I've had it for years. When I connect via IMAP, I see all of these folders, and I can decide which ones have messages that require my immediate attention. This is how I deal with the torrent of mail I receive every day. If I had a flat mailbox, I'd spend all my time reading mail! Furthermore, I can keep the state of all my folders on the server where it belongs, and all of the clients that I might care to use will have a consistent view of the world. This is important for people who want to read their email with mobile devices or multiple computers. -- Chris _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
