Re: Imap Backend Propsal

Ahh. Finally some time to respond to Richy' mail. > 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. Absolutely correct. I was thinking about caching emails, or emails stored in a database, both of which are/will be used in my program, but these could be easily reprogrammed to work differently, and would work better that way too:) Forget I ever said it :) > >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. Hmm, this sounds way to familiar, really. I've gone through exactly the same methods in perfecting my own webmail. I still have a huge pack of printouts of imap_fetchstructure gathered from submitted emails of several hundred users. It took a while, but I've assembled a nice group of strange mails, to see how my code'd react to it. I'll see if I still have them around somewhere, to see how they'd work with your code :) > 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. How would you split all these up best? Here's one idea I've been thinking off: * Mail_MessageFetch package that handles finding and fetching the right, or requested, parts of an email. Not a full wrapped for the imap_* functions, since not every server(Windows/WU-IMAP/Exchange) or connection-type (POP/IMAP/NNTP) will have the same capabilities. Since most won't be emulatable by PHP either, I think your package should not provide them directly, but should silently ignore such functions and focus on, what I see, to be its strongest point. Find and Fetch :) * Mail_MessageParse package that handles mangling an email in any form you might need. Auto hyperlinking, CID-substituions, HTML-conversations, cleanups, BBCode, things like this. By putting all this code in a seperate place, you can easily let this out. This way it's easy to just get the part you need, and then mangle it yourself in whichever way you might want to. Just thinking outloud here, ofcourse, but I don't think the later functions should be included in the main package. I also think that splitting up the code like this gives a nice balacne between usability, and performance. > 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. I don't think that reading files from sources like that should be part of the Mail_Message packages. There's already a Mail_MBOX which parses unix-style mailboxes, so it'd be best to create seperate Mail_O2K(or howeverly-named) packages which have similar interfaces as Mail_MBOX Cipriano