On Fri, 08 Nov 2002 15:12:01 -0300, Oliver Schulze L. wrote:
> The problem I trying to solve is in the php.net implementation of imap
> searching.
I understand. This has been a difficult problem.
Basically, my position has been that IMAP search strings, while "logical", are
a terrible interface from a human's point of view. Consider
FLAGGED OR FROM SMITH CC JONES
Most humans would interpret this as "messages which are flagged, or are from
SMITH and cc JONES". But that is not what IMAP does; in IMAP it means
"messages which are flagged, *and* are from SMITH or cc JONES."
I feel that the correct thing would be for PHP and/or the application to
provide an interface suitable for humans, as opposed to passing IMAP strings.
An additional complication, and what was fatal to mail_criteria(), is in the
handling of strings which require representation as a literal. Then, too,
mail_criteria() is very thread-unsafe...
One problem that people traditionally had was in generating the shortdates
expected by the date search criteria. imap-2002 now has a mail_shortdate()
function which should make this a lot easier.
> I was trying some examples of building a SEARCHPGM and could't find
> the way to have more than one criteria. Like when using OR/AND, etc
> How do I do this?
AND is easy. Just set multiple criteria in the SEARCHPGM. For example you
can do FLAGGED UNSEEN with:
SEARCHPGM *pgm = mail_newsearchpgm();
pgm->flagged = pgm->unseen = T;
OR is more complicated. You create a SEARCHPGM for each part of the OR'd
expression, and set them in the SEARCHOR in a higher SEARCHPGM. For example,
to do OR FLAGGED UNSEEN:
SEARCHPGM *pgm = mail_newsearchpgm();
pgm->or = mail_newsearchor();
pgm->or->first = mail_newsearchpgm();
pgm->or->first->flagged = T;
pgm->or->second = mail_newsearchpgm();
pgm->or->second->unseen = T;
This is actually expressing ALL OR FLAGGED UNSEEN, which is equivalent.
NOT works in a corresponding way; it is a linked list of SEARCHPGMs which are
"AND NOT" with the top level. For example, to do NOT FLAGGED NOT UNSEEN:
SEARCHPGM *pgm = mail_newsearchpgm();
pgm->not = mail_newsearchpgmlist();
pgm->not->pgm = mail_newsearchpgm();
pgm->not->pgm->flagged = T;
pgm->not->next = mail_newsearchpgmlist();
pgm->not->next->pgm = mail_newsearchpgm();
pgm->not->next->pgm->unseen = T;
Of course, this was a very silly example, since an equivalent search can be
done with UNFLAGGED SEEN:
SEARCHPGM *pgm = mail_newsearchpgm();
pgm->unflagged = pgm->seen = T;
NOT generally only happens with string searches, since most other search terms
already have logical opposites (thus making NOT extraneous).
Yes, I know that this all looks pretty imposing, but you have to think about
what the IMAP strings would look like. No normal mortal will be able to
comprehend RECENT OR FROM SMITH CC JONES correctly, so you will need your own
interface. It actually is easier, and less bug-prone, to generate a SEARCHPGM
than it is to try to figure out how IMAP expresses things.
But I understand that there can be a comprehension gap.
