On Thu, 21 Nov 2002, Oliver Schulze L. wrote:
> My point is that, if every c-client user must parse a IMAP4 serch string
> into a *SEARCHPGM, why do not let c-client does the job?
That's the whole point. Why should a c-client user deal with IMAP4 search
strings at all? IMAP4 search strings are for protocols, not for human
users.
> Imagine the this code:
> SEARCHPGM *my_search;
> my_search = imap4_to_searchpgm("FLAGGED OR FROM SMITH CC JONES");
> mail_search_full(imap_stream, NIL, my_search, flags);
This is a good example. You are assuming that SMITH and JONES are atomic
values, but they don't have to be. If non-atomic, then you have to know
how to apply IMAP quoting and literals. And with literals, you have
nesting (due to the OR) and a query/response.
So your simple example becomes a recursive call plus the send literal and
response.
Take a look at how imapd parses search commands if you don't believe me.
It may look a lot like mail_criteria(), but note those recursive calls and
callbacks. You can't do that with a char*.
That's why SEARCHPGM was created. And even if the tokens are atomic, I
challenge you to find any human who will guess the correct interpretation
of
FLAGGED OR FROM SMITH CC JONES
the first time.
You have to have a different representation of searching for your human
users. Why do we need *yet another* non-human representation of the same
thing?
> So, the PHP programer will pass a imap4 search string that was entered
> in a GUI by the user.
Why?
Once again, there is no such thing as an "IMAP4 search string". At best,
you can have a search string that's a subset of IMAP4. IMAP4 searches can
not be represented by a char*.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
