Re: Imap Backend Propsal

> >Also, I don't see the point to call your methods imapSomething. Just get rid of the imap > >prefix and we might be able to later have a Mail_POP3 class with the same API. > --This class mostly just wraps IMAP functions, thus I thought it helpful to name the > functions after what they were wrapping. But again, point taken. Abstraction is > always good! I've written my own webmail client with similar functions in the backend as this class proposes, and as such, I'm highly interrested in it. As you may or may not know, PHP's imap module can connect to IMAP, POP and NNTP via the same functions. Even the data returned will be nearly identical. There will be no need at all for a seperate Mail_POP3 class, since the Mail_IMAP package will access it just as easily as it would with IMAP. That said, I agree with Bertrand about the class name and function names. I'd suggest calling it Mail_Message, since it deals with parsing and reading of a message. Also, would it be possible to make the connecting to the server optional? I can see this class, as a seperate Mail_message parser being extremely helpfull in other scenarios such as parsing an email saved as a .eml file, parsing mail directly from a database or handling cached messages. It would also make it easier to implement the package in already existing environments. 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'm assuming that you, like me, started from scratch comparing to other clients and see if it'd end up with similar results? I know I've spend hours on perfecting the subpart matching algorithms, but found them alas to end up way to inefficient to ever dare show them to anyone else;) Also, let me know if you could use any help with this, I've had enough experience with the imap_* functions to know I don't wanna have to deal with them ever again ;) Cipriano