[cvs] [Wiki] changed: Project/HordeMime

[Chuck Hagenbuch]

chuck  Wed, 02 Apr 2008 23:40:46 -0400

Modified page: http://wiki.horde.org/Project/HordeMime
New Revision:  1.10
Change log:  use the project template, more or less

@@ -1,5 +1,19 @@
-+ Next MIME Library
+[[toc]]
+
++ 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 {{Horde_Mime}} (instead of just {{MIME}} - the case
change is also intentional). The code should also be updated to use PHP 5
features.
+
+++ Bugs
+
+[http://bugs.horde.org/ticket/?id=3580 Bug #3580]
+
+++ People
+
+Michael Slusarz has been the lead developer on the MIME package lately. 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.
+
+++ Description

 we would eventually like to refer to embedded mime parts by an id.  PGP
example:
 <code>
 0. multipart/signed
@@ -12,31 +26,29 @@
 </code>

 Then, if we want to access the image/jpeg option, we do a getPart('2.2')
call to the MIME_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
containsembedded 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.

-++ More notes
++++ More notes

 Status of work that needs to be done for the various MIME components.

-**MIME_Part** - Should do a better job of natively handling
'message/rfc822' parts - i.e. having a specific
'rfc822BasePart()/setrfc822BasePart()' methods to return/set the ID of the
message/rfc822 part that is the parent of the current part (rather than
using setInformation()/getInformation()).  For IMP, we may want to override
MIME_Part (esp. setContents()/getContents()) to obtain the information from
the IMAP server - although haven't decided yet whether this should remain in
IMP_Contents/MIME_Contents::, or even MIME_Viewer::.
+++++MIME_Part
+Should do a better job of natively handling 'message/rfc822' parts - i.e.
having a specific 'rfc822BasePart()/setrfc822BasePart()' methods to
return/set the ID of the message/rfc822 part that is the parent of the
current part (rather than using setInformation()/getInformation()).  For
IMP, we may want to override MIME_Part (esp. setContents()/getContents()) to
obtain the information from the IMAP server - although haven't decided yet
whether this should remain in IMP_Contents/MIME_Contents::, or even
MIME_Viewer::.

-**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.
+++++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.

-**MIME_Structure** - No major changes
+++++MIME_Structure
+No major changes

-**MIME_Headers** - Remove deprecated code.  Other than that, no major
changes.
+++++MIME_Headers
+Remove deprecated code.  Other than that, no major changes.

-**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.
+++++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.

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

-**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.
+++++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.

 //I think that we should retain the {{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//
-
-++ Relevant Tickets
-
-[http://bugs.horde.org/ticket/?id=3580 Bug #3580]
-
-++ Naming Notes
-
-All code that remains in the framework should be changed to have the prefix
{{Horde_Mime}} (instead of just {{MIME}} - the case change is also
intentional). The code should also be updated to use PHP 5 features.