manipulating an IMAP account

[David Mintz-3]

If you were working on a Zend Framework application, and if you were writing a simple script to log into an IMAP email account, fetch messages, iterate through them finding ones matching particular criteria, do something with the information in each of those messages, delete the message, and call it a day... And if you found that Zend_Mail_Storage_Imap has a flawed implementation of removeMessage(), because it sends an EXPUNGE command on every invocation and thereby screws up the class'  ArrayAccess implementation by disrupting the mapping between message numbers and messages... then what would you do?

One option that occurs to me is to extend Zend_Mail_Storage_Imap and override the parts that are giving me grief. But.... is that sound practice?

Another option: write it in another language entirely. I happen to speak Perl. Anybody want to recommend a mature IMAP client module?

Another option: seize the opportunity to write it in some language I don't know, being an ADD-afflicted sort who I loves running off on tangents... Ruby? Python?

Any other suggestions?

--
David Mintz
http://davidmintz.org/

The subtle source is clear and bright
The tributary streams flow through the darkness

_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/Show-Participation

[John Campbell-6]

On Fri, Oct 2, 2009 at 11:21 AM, David Mintz <david@...> wrote:
> If you were working on a Zend Framework application, and if you were writing
> a simple script to log into an IMAP email account, fetch messages, iterate
> through them finding ones matching particular criteria, do something with
> the information in each of those messages, delete the message, and call it a
> day... And if you found that Zend_Mail_Storage_Imap has a flawed
> implementation of removeMessage(), because it sends an EXPUNGE command on
> every invocation and thereby screws up the class'  ArrayAccess
> implementation by disrupting the mapping between message numbers and
> messages... then what would you do?

So, let me make sure I understand this correctly.  Expunge, iirc,
deletes everything marked for deletion, and ZEND calls expunge
immediately after you mark something for deletion, which is not quite
right (but, makes imap behave more like pop).  It is unlikely the
class maintainers are going to change that.

How is the ArrayAccess broken?  The key=>message mapping should change
every time you call delete.

Regards,
John Campbell
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/Show-Participation

[David Mintz-2]

On Fri, Oct 2, 2009 at 12:04 PM, John Campbell <jcampbell1@...> wrote:

On Fri, Oct 2, 2009 at 11:21 AM, David Mintz <david@...> wrote:
> If you were working on a Zend Framework application, and if you were writing
> a simple script to log into an IMAP email account, fetch messages, iterate
> through them finding ones matching particular criteria, do something with
> the information in each of those messages, delete the message, and call it a
> day... And if you found that Zend_Mail_Storage_Imap has a flawed
> implementation of removeMessage(), because it sends an EXPUNGE command on
> every invocation and thereby screws up the class'  ArrayAccess
> implementation by disrupting the mapping between message numbers and
> messages... then what would you do?

So, let me make sure I understand this correctly.  Expunge, iirc,
deletes everything marked for deletion, and ZEND calls expunge
immediately after you mark something for deletion, which is not quite
right (but, makes imap behave more like pop).  It is unlikely the
class maintainers are going to change that.

How is the ArrayAccess broken?  The key=>message mapping should change
every time you call delete.

I think that's exactly the problem. http://framework.zend.com/issues/browse/ZF-5655 explains it better than I can.

And, since my initial post, I went ahead and wrote my own extension stealing all the suggestions provided in the above link.  It works.

Whoever wrote removeMessage() apparently did have some misgivings about EXPUNGE. Note the TODO comment:

    public function removeMessage($id)
    {
        if (!$this->_protocol->store(array(Zend_Mail_Storage::FLAG_DELETED), $id, null, '+')) {
            /**
             * @see Zend_Mail_Storage_Exception
             */
            require_once 'Zend/Mail/Storage/Exception.php';
            throw new Zend_Mail_Storage_Exception('cannot set deleted flag');
        }
        // TODO: expunge here or at close? we can handle an error here better and are more fail safe
        if (!$this->_protocol->expunge()) {
            /**
             * @see Zend_Mail_Storage_Exception
             */
            require_once 'Zend/Mail/Storage/Exception.php';
            throw new Zend_Mail_Storage_Exception('message marked as deleted, but could not expunge');
        }
    }

I overwrote this method, simply moving the expunge part to  __destruct()


--
David Mintz
http://davidmintz.org/

The subtle source is clear and bright
The tributary streams flow through the darkness

_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/Show-Participation

[Daniel Convissor-2]

Hey David:

> One option that occurs to me is to extend Zend_Mail_Storage_Imap and
> override the parts that are giving me grief. But.... is that sound practice?

It's excellent practice.  This way you get the benefits of the original
class and the benefits of of the fix, all without having to modify the
original class file.

Going one step further is to open a bug report (which I see someone has).

The next level of karma is obtained by checking out the project in
SVN/CVS/whatever, fixing the problem and submitting the output of
"<cvs/svn/whatever> diff" onto the bug report.

And if you want to reach nirvana, you'll modify and enhance the related
unit tests and submit those along with the bug report.

--Dan

--
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
            data intensive web and database programming
                http://www.AnalysisAndSolutions.com/
 4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/Show-Participation

[David Mintz-2]

On Sun, Oct 4, 2009 at 11:59 AM, Daniel Convissor <danielc@...> wrote:

Hey David:

> One option that occurs to me is to extend Zend_Mail_Storage_Imap and
> override the parts that are giving me grief. But.... is that sound practice?

It's excellent practice.  This way you get the benefits of the original
class and the benefits of of the fix, all without having to modify the
original class file.

Well, I did it and it works, or so it seems. My only hesitation was because I generally think of extension as a means of enhancing or specializing the parent class rather than correcting its flaws.

 

Going one step further is to open a bug report (which I see someone has).

The next level of karma is obtained by checking out the project in
SVN/CVS/whatever, fixing the problem and submitting the output of
"<cvs/svn/whatever> diff" onto the bug report.

There's not a shred of originality in my solution, someone else wrote the code (the guy who filed the issue) and I merely put some pieces together. But... with attribution to the source, why not.

 

And if you want to reach nirvana, you'll modify and enhance the related
unit tests and submit those along with the bug report.

And learn something about unit testing an IMAP client in the process -- nice. Thanks.
 

--
David Mintz
http://davidmintz.org/

The subtle source is clear and bright
The tributary streams flow through the darkness

_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/Show-Participation