Re: Imap Backend Propsal

Wow, lots of discussion on this. First, Cipriano, Connection to the server couldn't be optional for some portions of the class because the resource is a required argument. I do see the neccessity for what you're talking about though with a Mail_Message package, and I have many functions already written that do exactly that. I began developing this class for my own web-based email client, and have been abstracting that functionality for this package. >Another question I've had since reading this thread, where did you get the >information you're using on parsing the messageparts, and others? I started from nothing using trial and error and one or two poorly written tutorial scripts. I haven't been able to find any fantastic documentation on c-client. I've used a variety of test messages and spent a lot of time feeding part numbers to imap_fetchbody to see which ones it liked and which ones it didn't (which I eventually figured out that it returned NULL if it couldn't retrieve a body). And I've been using these algorithms in my web-based email program since I came up with them. So far they've held up well. I have noticed one or two holes with my header pid selection function. I think it will be interesting to go alpha/beta with this project and see how it holds up in real world use. I've been developing this program for the past several months, adjusting the backend every time a message popped up that it couldn't read, or didn't quite display right, comparing what I saw in the message to what I was seeing in Microsoft Outlook. Stepha, >Since you're parsing mainly the headers and MIME-structure of a message, >wouldn't it be a good idea to integrate this into Mail_Mime? No more class >would be needed, and since Mail_Mime currently handeles generation of a MIME- >message it might then also support parsing as well as "parse, modify and sent >our again" or something. Just a thought ... I don't think so, I use Richard Heyes' class in my web-based email, so I am familar with it. The fact remains that for what I am doing, Mail_Mime would just be 'bloated' adding all this c-client functionality to it, because you don't have to want access to an email account to have the need to create MIME messages, his class is implementable in more than one type of situation. And not to mention, c-client isn't always available! Bertrand, >About your helper methods, they should belong to some other class as they >could be used by other packages as well (think about Mail_POP3...). I agree. I think the helper package should do regular expressions for hyperlink conversion, cid substitution in multipart/related messages, forum/BB syntax, a function to detect <html> tags in the beginning of a plain text message. I think that a Mail_Message package for .eml parsing should have a number of features, Since it would be used with several packages use mailparse or Richard Heyes' parsing package or C-client (rfc822 functions), since c-client is faster and mailparse is still experimental, which BTW, Cipri, those particular functions don't rely on a connection being set. 1.) Message Storage in a database. 2.) Message Storage in a flat file. 3.) Importing messages via .csv or whatever from popular mail programs. I've written a great deal of that functionality already. A Mail_Message package should account for a number of variations in how message content is stored, Outlook 2000 stores address lists, headers are already separated, and the message body, not much more, and doesn't export in multipart/mixed format. Mozilla, the same. So you think there should be a header member variable which contains all header information? I could simply clean up the information that needs to be cleaned up and store it back in the object created by imap_headerinfo/imap_rfc822_parse_headers. Well I supose that wouldn't work becaus imap_rfc822_parse_headers does not create a udate field. But I see where you're going with it, a singular array that holds all of the information. Best Regards, Richard York