Re: Imap Backend Propsal

<richy@smilingsouls.net> wrote : > Hello, > First let me announce that I am pretty new to PEAR, but have been programming > in PHP for about three years or so. > I have a package proposal for inclusion in PEAR that deals with creating an > interface that simplifies use of certain IMAP (c-client) functions. I came > about this decision after spending months attempting to perfect a web-based > email program which relies on this functionality, namely the parts that deal > with parsing the structure of a multipart message using imap_fetchstructure, > and finding the correct part numbers to supply to the imap_fetchbody function. > I have a good deal of my package already put together and written for the PEAR > standard. > It is attempting to accomplish.. > > 1.) It parses the object returned by imap_fetchstructure to come up with a > complete list of part numbers, as well as other part information, file type, > file size, encoding, etc. This information is then used in a variety of ways. > Another function looks at this information and determines which part should be > the top level default part to display.. it selects text/html over text/plain > parts when possible. > > 2.) Another member function may be used to return inline/attachment parts that > relate directly to the part being displayed. These are set up as member > variables and may be accessed by the user to create links to the attachment > parts. > > 3.) Yet another member function deals with the headers, and again depending on > which part is currently being displayed, sets up member variables containing > information parsed from imap header functions. > > 4.) Another member function deals with selecting the correct message body to > return from imap_fetchbody, depending on whether an attachment has been > selected, and whether that attachment is an message/rfc822 part. The function > also decodes the message part and returns the body. > > All of these functions boil down to just a few things, the user supplies a > message id, a link to the imap resource stream, and the part id, via clicking > an attachment or by the application selecting a default part id. > > This package is unique, in that I have not seen any examples tht deal with > c-client specifically. Although I realize that for portability purposes, many > seeking to build a web-based mail client typically seek a solution which is > already available in the core PHP install. > > I have other ideas for inclusion in the package as well, > First some utility functions, > A function that converts the plain text links in a message body to clickable > hyperlinks, parses forum code, like that used in PHPBB and Snitz, highlights > PHP syntax, if any is present, and allows for a style sheet to be set for a > plain text message part. > > My preliminary proposal is pretty simple though.. no bells and whistles just > yet : ) > Here are links to the code I've already completed: > > http://www.smilingsouls.net/common_include/pear/imap/imap.mailbox.phps > AND inbox example: > > http://www.smilingsouls.net/common_include/pear/imap/imap.inbox.phps > AND message viewer example: > > http://www.smilingsouls.net/common_include/pear/imap/imap.message.phps > > This code when supplied a pop3/imap mail account, username and password should > show an example inbox. Which demonstrates the simplified approach to creating > an inbox and displaying a multipart message. > > This is the only line you should need to modify to test the code, > $msg =& new > Mail_ImapMailbox(imap_open('{mail.yourhost.com:110/pop3/notls}INBOX', > 'user', > 'pass')); > > Which appears in the latter two files at the top of each file. > > There are at least one or two bugs that I am aware of and working on a fix > for! One being in the default part id picker. > > So there you have it, it took about an hour or so to put together the inbox > and message viewer example, which are pretty bare, but show how powerful the > imap backend can be in terms of parsing multipart messages and simplifying the > imap backend. > > I am still working on documention! But the example scripts are very short and > *should* be easy to follow. I do promise thorough documentation! I did want > to get some feedback from the PEAR group before getting too deep in the > project! Hi Richard, This is looking good. Please use Pepr to make your proposal, I will vote +1 for it. This seems to be a compilation of methods we keep on rewriting all the time in order to work with the imap extension. Notes: ------ I am not sure I understand the use of NULLHOST.COM with imap_rfc822_parse_headers() in method Mail_ImapMailbox::ImapGetHeaders() I don't think Mail_ImapMailbox::_getUdate() adds anything to strtotime() native php function but I might be wrong... Function names shouldn't start with uppercase. Maybe you shouldn't worry about declaring all instance vars and instead have them dynamically instantiated according to the content of the mail. Some CS cleanup (tabs, for(), foreach()...). I'd add an imapGetRawMessage() method that would return the complete message without parsing. I'd be extra careful with memory and use some unset() or a free() method if necessary although I am not sure it is useful with php. Bertrand Mansion Mamasam