\documentclass{article}
\usepackage{ulem}
\pagestyle{headings}
\begin{document}
\tableofcontents

Horde\_MimeBugsPeopleDescriptionMore notesMIME\_PartMIME\_MessageMIME\_StructureMIME\_HeadersMIME\_ContentsMIME\_Viewer

\part{Horde\_Mime}
The MIME packages need to be rewritten in BC-breaking ways to add features and for Horde 4.0. All code that remains in the framework should be changed to have the prefix \texttt{Horde\_Mime} (instead of just \texttt{MIME} - the case change is also intentional). The code should also be updated to use PHP 5 features.

\section{Bugs}
Bug \#1866\footnote{http://bugs.horde.org/ticket/1866} \textbf{FIXED}\newline
Bug \#3580\footnote{http://bugs.horde.org/ticket/3580} \textbf{FIXED}

\section{People}
Michael Slusarz has been the lead developer on the MIME package lately. He is actively working on portions of this project in association with creating the new Horde IMAP library. Jan Schneider has done work on it as well. Chuck Hagenbuch is not an expert in the current code but is interested in this project and knows the area in general.

\section{Description}
we would eventually like to refer to embedded mime parts by an id.  PGP example:\newline
\begin{verbatim}

0. multipart/signed
  1. encryption signature/version stuff
  2. encryped data
    Encrypted data contains:
    1. multipart/mixed
      1. text/plain
      2. image/jpeg
\end{verbatim}

Then, if we want to access the image/jpeg option, we do a getPart('2.2') call to the IMP\_Contents:: object and it will be responsible for rebuilding the data (it sees that 2.2 doesn't exist on the IMAP server, but that id 2 contains embedded data, so it automatically downloads/parses as many parent parts as required to build down to the requested part).  This will eliminate the need for MIME specific caching - which was always kind of a hackish implementation by me I admit. \textbf{FIXED}

\subsection{More notes}
Status of work that needs to be done for the various MIME components.

\subsubsection{MIME\_Part}
\subsubsection{MIME\_Message}
No major changes.  Maybe try to clean up rebuild code a bit - but it works so don't mess with it too much. Moved parsing of message from the old MIME\_Structure into this.

\subsubsection{MIME\_Structure}
Will be removed.  Parsing functions will be moved to MIME\_Message and MIME\_Headers. \textbf{REMOVED}

\subsubsection{MIME\_Headers}
Remove deprecated code.  Remove all c-client specific code.  Library will focus exclusively on parsing Headers and presenting an easy to use access to header fields (with associated MIME decoding).  All functions relating to UI display (such as altering headers in preparation for display) will be removed.

\subsubsection{MIME\_Contents}
I believe that the benefits of code sharing is fairly slight when faced with the disadvantages of BC issues.  Therefore, I propose removing MIME\_Contents completely and instead maintaining the code entirely within IMP.  Since the output should really be controlled at the app level, it doesn't make too much sense to try to have a shared library handle it.  Remove caching code from MIME\_Contents.  Possibly have IMP's MIME\_Part or MIME\_Viewer extending class do the retrieval of the text of a part from the server instead of MIME\_Contents.

\textsl{I agree - especially since Troll is now gone and MIMP and DIMP use IMP, this belongs entirely in IMP. --ChuckHagenbuch}

\subsubsection{MIME\_Viewer}
MIME\_Viewer should be extended to do more than just render the MIME\_Part in html format.  It should do a better job of indicating the parts underneath it, whether a part is an 'attachment' or not, prepare the summary information for the part (instead of MIME\_Contents).  Once again, some of this additional functionality may be best implemented by extending MIME\_Viewer in IMP.

\textsl{I think that we should retain the \texttt{Viewer} concept as something separate from the MIME libraries, but that things like message/rfc822 and encrypted part handling probably should be email-specific. --ChuckHagenbuch}

\end{document}
