PHP IMAP alternative

Oh man, this is super awesome!! Actually, that is a 'key' to succeed in get rid of the imap extension as long as making the pifr infrastructure able to test the module.

I'll tag this to be completed before we go for the 7.x version!

This is a very big patch however, we need to split up code into 'functional chuncks' that we are able to test, and make sure they work before removing the imap dependency. Let me make a review and I'll update the issue with appropiate tasks.

Thanks so much!

mmm patch will not apply because you have to use relative paths in the patch file (http://drupal.org/patch/create) :

--- mailhandler/mailhandler.install	2010-02-01 14:27:09.000000000 +0100
+++ /var/www/htdocs/drupaltest/sites/all/modules/mailhandler/mailhandler.install	2011-01-25 15:13:54.000000000 +0100

should be:

--- mailhandler.install
+++ mailhandler.istall

Unfortunatelly, there are no tests for the IMAP part, so even if test results are ok, the patch might fail in its purpose.

@pe1rxq, can you confirm that this code is GPL licensed or any Drupal compatible license?

has anyone tested this? thanks pe1rxq for making this gpl!

mailhandler.user_imap.patch queued for re-testing.

+1

I doubt this will make it into 6.x-1.x or 7.x-1.x, but please consider working on integrating it into 6.x-2.x / 7.x-2.x: #1357638: Alternative to PHP IMAP retrieval library

All you'd need to do is copy MailhandlerPhpImapRetrieve.class.php and MailhandlerPhpImapRetrieve.inc.

Actually I'm going to mark #1357638: Alternative to PHP IMAP retrieval library as duplicate, so we can concentrate effort in this issue. This should be relatively easy to port between 1.x/2.x, as I mentioned in #12.

Another possible library to use: http://www.phpclasses.org/browse/package/2351.html

Finally, if 3rd-party code is used (if it is primarily hosted and maintained somewhere other than on drupal.org), then it should be included as a Library, and not distributed with Mailhandler.

@ArchGalileu There's currently no alternative to the PHP IMAP module / extension. That's what this issue is advocating :) If you are looking to help with development, what needs to happen is to clone the mailhandler_php_imap module, making sure to define the retrieve(), test(), and purge_message() functions.

I did an extensive search for possible PHP IMAP alternatives, and here are the best two:
Horde IMAP client library
Net_IMAP (PEAR)

Those are most desirable because they are open-source and currently-maintained on well-known frameworks.

Other options, probably not ideal, are the OP's patch and the code snippet linked to in #13.

Again, all that needs to happen is to clone the mailhandler_php_imap module and rewrite the retrieve(), test(), and purge_message() functions to use the new library rather than PHP IMAP functions.

Hi. What is the status of this effort? I'd like to enable mailhandler on my Go Daddy shared hosting Drupal 7.x-2.x site and believe I need something like this IMAP alternative to do that. The discussion so far makes it sound like that is not yet possible.

Thanks
-- Hank

Looks like Horde IMAP is indeed state of the art and seems to be well supported.
We can also use the performance boost they're advertising, especially the optional integration with imapproxy sounds interesting.
If it really proves to be faster than native PHPIMAP, we could even make this default and drop the PHPIMAP extension requirement.

While the library does much more than we need, we're finally a framework, and well-supported third party code is clearly preferable to custom code that we have to support ourselves.
Assuming that it should be GPL-compatible but can't find any concrete license information though.

@hank - Correct, not yet possible. If you're interested in sponsoring development let me know, but this would be a pretty big project and I don't have plans to undertake it at this time.

Seems great! The instructions are pretty clear:

Again, all that needs to happen is to clone the mailhandler_php_imap module and rewrite the retrieve(), test(), and purge_message() functions to use the new library rather than PHP IMAP functions.

If someone wants to take this on I think it would be a great addition. Any 3rd party libraries used should be included with the Libraries API module. If someone was interested in porting the original patch to a full class, then this would work for hosts without php-imap installed. The original patch does not look appropriate for the module anymore though.

Happy to take a look at patches but not going to implement this myself.