Diff for Project/HordeMime between 4 and 5

+ Next MIME Library



From Michael Slusarz:



What Iwe would eventually like is to refer to these embedded mime parts by an id.  PGP example:

<code>

0. multipart/signed

  1. encryption signature/version stuff

  2. encryped data

    Encrypted data contains:

    1. multipart/mixed

      1. text/plain

      2. image/jpeg

</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 can contain embeddedcontainsembedded data, so it automatically downloads/parses as many parent parts as required).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



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_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_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 (and Troll).  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 retrievedo the retrieval of the text of a part from the server instead of MIME_Contents.



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