RE: [PEAR-DEV] Imap Backend Propsal

>* 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 :) I agree that a package should exist which could work when c-client functions are not present or available, but I think that package should be developed separately from mine and possibly a third package could be used as a wrapper to decide whether c-client is present, if so, use c-client functionality, if not, use a raw socket connection, but provide a singular API between the two. And I'm just putting some ideas out there, or perhaps a package that makes use of Net_IMAP or Net_POP3, but simply includes the message retrieval (multipart selection) aspects of that. Including all of the functionality in a single package would create excess overhead. And I know we're just tossing about ideas here.. but that kind of solution IMHO would provide the most conservative approach in those respects. I also think that my package answers a need specific to users of c-client, and some may not want any alternative functionality. My package is far from being a complete solution to c-client, while I think it addresses the basics very well, I hope to continue to develop and add in additional functionality over time, including functionality which address the administrative aspects, probably in a separate class, but bundled in the same package, possibly as a parent or child class. As well as adding functionality for moving messages to sub-folders on the server. I've spent so much time getting imap_fetchstructure and imap_fetchbody functionality correct that I haven't had much time to even look at other functions. >* 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. I'm thinking of a series of small, very light-weight classes, in which the functions would most likely be called statically. Each preforms a task, but without need for contact with any of the others, that way, the designer can include the code for those tasks which are required at the time, without waste from including code that won't be used. Which could also be used in other applications, outside the scope of email (with the exception of CID substitution). I have just discovered that there is already a BB Code parser in the HTML category, so that part isn't neccessary. >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 agree, I think they should be in a separate package, perhaps under the HTML category. >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've made quite a few diagrams myself. And I would appreciate any testing that you could offer. I do have the two bugs that I talked about eariler to address and I plan on getting to those in the next day or two. Best Regards, Richard York