[imp] IMP with IMAP2001a c-client

[Shawn Robinson]

At 02:10 AM 2002/05/29 +0200, Jan Schneider wrote:
>Zitat von Shawn Robinson <Shawn.Robinson@telus.com>:
>
> > 1) ensure the OP_SILENT is set on all imap stream opens.
>
>This sounds interesting, but this flag isn't mentioned in the php manual. I
>didn't have the time to look inside the source code, but is it it defined
>anywhere?

It's included in php4.1.2/ext/imap/php_imap.c as a flag, and there is a 
reference to it in the uwash documentation at 
http://www.washington.edu/imap/documentation/internal.txt.html (search for 
OP_SILENT)


> > 2) patch the php4*/ext/imap/php_imap.c mm_log() routine to eat errors
> > 3) hack at the imap client lib to remove the errors
>
>This is obviously no general solution. At least for this mailing list.
>
> > 4) eat the errors after most/all imap calls in IMP. using imap_errors() ?
>
>This function only returns the last error messages but doesn't prevent the
>c-client from being so loud.

 From php.net:
array imap_errors ( void)
  This function returns an array of all of the IMAP error messages
  generated since the last imap_errors() call, or the beginning of
  the page. When imap_errors() is called, the error stack is
subsequently cleared.

So, it looks to me like it will clear the error stack of accumulated 
errors, but these errors are never read and presented.

However, I just found a snippet in imp/status.php that inlcudes a call to 
imap_alerts(), which is also fed via the mm_log call in the imap sources.


 >if (isset($imp['stream'])) {
 >    $alerts = imap_alerts();
 >   if (is_array($alerts)) {
 >        foreach ($alerts as $alert) {
 >            Horde::raiseMessage($alert, HORDE_MESSAGE);
 >        }
 >    }
 >}

I'll lose the raiseMessage, and I bet this will clear up my griefs.  Any 
ideas on what could break, or why the imap_alerts() call is in status.php?


Thanks,
Shawn Robinson