Hi Mark,
thanks for the examples and explanations. Sorry about the delay ...

I understand your point, but the parsing I'm talking about is the
parsing of a IMAP4 search string. Not a search string entered
by the user.

I think if there is a function that parses an IMAP4 search string
into an *SEARCHPGM, it will help programers that use the
c-client library.

In the PHP example, this is what should happend:
- the PHP programer parse a human redeable search string
  into an IMAP4 search string
- the PHP developer use this IMAP4 search string and convert it
  to a *SEARCHPGM using a parsing function
- the PHP developer then pass this *SEARCHPGM to the function
  imap_search()
- What happend is that work of the PHP developer is more easier and
  the PHP programer does the human-to-imap4 search string convertion.

This proposed parsing function will make it easier for c-client users,
like PHP, to implement IMAP4 search strings. Right now, PHP does
not support IMAP4 search strings because of the lack of this function.

Let me know what you think about this new IMAP4 search string
to SEARCHPGM parsing function.

Regards
Oliver

Mark Crispin wrote:

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.

--
Oliver Schulze L.
<[EMAIL PROTECTED]>


Reply via email to