From: Jonathan A. <jo...@sq...> - 2005-11-29 06:41:26
|
Hi Michael, On Wednesday, November 23, 2005 you wrote: > STATUS "MAILBOX" (MESSAGES UNSEEN RECENT) > Depending on configuration, this could be called up to three times for > each mailbox > Once by the newmail plugin > Once by the filters plugin > Once by sqimap_get_status_mbx_tree() > By creating a global array $global_mailbox_status, the calls can be cut > to 1/3 > This eliminates 2/3 of the calls for "STATUS MAILBOX (MESSAGES UNSEEN=20 > RECENT)" Another option would possibly be to consider a hook in that function that triggers plugins with the results (obviously including mailbox). That then gives plugin authors a better way to see if they need to do their thing on the folder. > Also fixed a few bugs in filters plugin so i could test the caching... > (This is what I had to do to get it work against my imap server...this > may need to be checked for compatibility!) > start_filters() - $key was being overwritten, resulting in imap > password being lost *ahem* That would have been me. For some reason, this never caused an issue for me... fixed. Code hasn't yet been backported to stable yet, though I'm considering it at the moment, it already cuts down IMAP calls over the stable by the simple code order change. > start_filters() - failed imap connection never showed error since $hide > flag was set to 10 (previously timeout?) Not sure on this, but do you want to show an error? There are times that the imap server will timeout due to the fact that you have multiple connections open in excessive of the limit, and it will hold the connection until timeout. I'm not sure you'd need to show the error, just silently fail it. > filter_search_and_delete() - if !allow_charset_search, don't try to do > a CHARSET US-ASCII search, and dont use { } CHARSET US-ASCII MUST be supported per RFCs, which means we /can/ do it, though I'm not entirely sure of the reason behind doing it. Marc? > filter_search_and_delete() - change call to sqimap_run_command so it=20 > doesn't do "UID" prefix Why not? Maybe I missed something here, but surely you want the UIDs back, and not the messages' sequence number at the time you selected the mailbox? > filter_search_and_delete() - add double quotes on the search criteria > ($where) Code used literal characters {#} to allow for special characters. You code change would die if the user search for: "bob and jill" Including the double quotes. That doesn't even come to count all the fun affects using fancy characters can have to IMAP commands, however I believe there /is/ a bug there in that the literal code /should/ be waiting for a response from the IMAP server before spouting the actual search data. The RFC specifically states: A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, close brace ("}"), and CRLF. In the case of literals transmitted from server to client, the CRLF is immediately followed by the octet data. In the case of literals transmitted from client to server, the client MUST wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command). We appear not to be doing that, which is bad, and should probably be fixed. =20 --=20 Jonathan Angliss <jo...@sq...> |