[dev] Fwd: [PEAR-DEV] Imap Backend Propsal

[Chuck Hagenbuch]

Obviously we already have code that covers most of this. I haven't looked at the
code, but it might be worth someone scanning it to see if there are any
ideas/optimizations that we can learn from.

----- Forwarded message from richy at smilingsouls.net -----
    Date: Thu, 29 Jan 2004 02:44:45 -0500 (EST)
    From: Richard York <richy at smilingsouls.net>
Reply-To: Richard York <richy at smilingsouls.net>
 Subject: [PEAR-DEV] Imap Backend Propsal
      To: pear-dev at lists.php.net

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!

Thanks!
: )
Richard York

mailto:richy at smilingsouls.net
http://www.smilingsouls.net

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

----- End forwarded message -----


-chuck

--
Charles Hagenbuch, <chuck at horde.org>
"Here, I brought some cole slaw. It's made from peeeooople! Just kidding."