Chris has been explaining to me, off list, that imap users have a cloud mentality, at least for their emails. Emails live on the server and can be viewed and manipulated from various computers and devices. So when would you want to download an email? This is relevant, as I have been working on presentMail() in fetchmail.c, trying to make it serve the needs of pop and imap simultaneously, which I definitely think I can do. Much of this routine downloads an email from server to local computer. This is standard fair for pop, but when would you ever want to do this in imap?
1. You want the attachments. There is perhaps a program or document or wave file or something you really need on your computer. To this end I have implemented an a command to scan through attachments. These are saved to files as you designate, in real time, just like they are today if you are saving a formatted email from pop. I'm reusing that machinery, and this was not hard to do. So set that one aside and ask when you really want to save the entire email? Not to archive it; it is already archived in imap. If you just want to save it for the future then you don't need to save it at all. 2. The reason you would pull it down to your local computer, 99% of the time, is to compose a reply. Composing is writing, and you would want the power of edbrowse, at least I would. I would want my familiar editor. So I save to a local file, exit the imap client, bring up edbrowse on the local file, browse it (if I saved it unformatted), you can skip this step if you save it formatted, type re to set up the reply headers, put > in front of some lines you want to reference, type some more thoughts, edit and type, and then type sm to send the mail. Then most likely you could delete the file from your local computer; the mail is still on imap. You don't need to keep it any more. Well that all works but it seems like a lot of steps. Should I be using a different paradigm? When edbrowse is a pop client that's all it is, fetching mail down to your computer and asking you what you want to do with each email, save or delete or whatever. But there are other models. When I access an sql database, which I don't think any of you do, but when I do, database access is just another edbrowse session, though having some unique characteristics. Other edbrowse sessions are just editors or web browsers. So ... what if edbrowse was brought up as an editor browser, and in one of your sessions you typed imap 3 This would start an imap client using the third mail block in your config file. That session then runs all the commands Chris and I have been talking about. When looking through emails, type w to write the email to your computer, and when it asks for a file name, you can still enter one, like the pop world, but, like the ftp and http downloads we've been working on, you could just type a space to pull the file down into memory. Now it's an edbrowse session. Type re to set up the reply headers, edit, add text, add your thoughts, and type sm to send the reply. Then hit ^ to go back to the imap session. I think once we got use to it, this would be clean and easy. It's different from pop though, and I'd have more work to do on presentMail() and across the board. Today it manages the email in session 1, always session 1, because edbrowse is not an editor at that point, so it's hard coded and dedicated to a specific buffer that it uses over and over again. I would have to change this to say: if imap then push the email onto a new window in the current session, whatever session that is, and browse it, and let the user edit it or whatever. So this is different, and more work to implement, but might be worth it. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
