[jira] [Commented] (ZETACOMP-79) Add Iterate method to ezcMailParser and allow access through uids through intermediate ezcMailInfo struct

["Tolan Blundell (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ZETACOMP-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132585#comment-13132585 ] 

Tolan Blundell commented on ZETACOMP-79:
----------------------------------------

I think I've found a couple of issues with the patch. Apologies if I'm misunderstanding anything.

In the constructor for ezcMailParserIterator, it seems the following:

$this->referencableSet = ($set instanceof ezcMailParserReferenceableSet);

should be

$this->referencableSet = ($set instanceof ezcMailReferenceableParserSet);

Also, ezcMailRfc822Parser doesn't seem to reset itself when finish() is called, so if there are two emails in the set then the second when iterated to contains the body of the first, in addition to its own. Moving the initialisation of ezcMailParserIterator::$partParser from the ezcMailParserIterator constructor to the top of ezcMailParserIterator::parseMail() seems to solve this, though I'm not sure if it's the best way to fix it. It would seem to make sense to have ezcMailRfc822Parser::finish() reset the parser's state, but I have no idea if that would have knock-on effects elsewhere.
                
> Add Iterate method to ezcMailParser and allow access through uids through intermediate ezcMailInfo struct
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: ZETACOMP-79
>                 URL: https://issues.apache.org/jira/browse/ZETACOMP-79
>             Project: Zeta Components
>          Issue Type: New Feature
>          Components: Mail
>            Reporter: Benjamin Eberlei
>         Attachments: zeta_mail_referenceableset_parseriterator.patch
>
>
> There are several problems with the ezcMailParser at the moment:
> 1. It parses all mails at once, creating unnecessary memory overhead (although attachments are already handled very efficently)
> 2. It does not expose information about the UID (in case of IMAP) that this mail belonged to. Without this information there is no way to reference the parsed mail for further actions.
> Solution:
> Add a new method ezcMailParser->iterate method that returns an iterator spitting out ezcMailInfo structs lazily (prototype impl):
> class ezcMailInfo
> {
>     /** Optional, null  if the set is NOT a ezcMailReferencableParserSet */
>     public $id = null;
>     /** @var ezcMail */
>     public $mail;
> }
> The ID property contains the reference id for the underlying transport, for example with IMAP the UID.
> With this idea there comes a problem. The ezcMailParser currently has no access to the UID of the ezcMailImapSet. That means we have to introduce a new interface:
> interface ezcMailReferencableParserSet
> {
>     public function getCurrentUniqueMessageId();
> }
> The IMAP Transport has to implement it and return the UID (or null if uidReference = false). The Parser could then use this information to access the message id.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira