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

["Benjamin Eberlei (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ZETACOMP-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Eberlei updated ZETACOMP-79:
-------------------------------------

    Description: 
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.

  was:
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):

{code}
class ezcMailInfo
{
    /** Optional, null  if the set is NOT a ezcMailReferencableParserSet */
    public $id = null;
    /** @var ezcMail */
    public $mail;
}
{code}

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:

{code}
interface ezcMailReferencableParserSet
{
    public function getCurrentUniqueMessageId();
}
{code}

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.


> 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
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira