SearchQuery high level struct interface needs refining

[Laeeth]

working

• for boolean OR, pass an array of SearchQuery
• for boolean AND, set conditions within SearchQery
• for boolean NOT, set not in SearchQuery to true: this will NOT all conditions within the struct

missing

• no way to specify A and NOT B.

[otrho]

It's generally confusing. There's search, esearch, multiSearch which are similar but different. I think using a builder pattern is what we want here (assuming we don't already -- I can't make heads nor tails of it yet).

A builder pattern might let A and NOT B work as query(a).and(query.not(b)).

[Laeeth]

Search, esearch and multisearch do different things on the server and we should make sure the primitives are still there even if we call them rawSearch or whatever. Irritatingly nobody implements the multi mailbox search even though its a standard. So would be nice to have a function that does that the hard way.

Builder pattern sounds good

[otrho]

I want to fix the structured query/search for SIL before the library gets used by non-developers and am wondering what the best (i.e., most idiomatic SIL-like) approach would be.

A search is a bunch of terms like whether a string is in a header, whether a flag is set, some date oriented criteria, etc., with boolean composition. ANDing the terms binds more tightly than ORing them, and any term or expression can be NOTed.

I was thinking something along the following, where each of these examples is actually the same, and the result is passed on to a search function (or composed further if need be):

// Maybe start with an empty and then  OR more in.  Terms in an array are ANDed together.
query
  |> orAll([flags(Unseen), older(3600)])
  |> or(not(subject("hello")))

// Or start with a non-empty.
queryAll([flags(Unseen), older(3600)])
  |> or(not(subject("hello")))

// Same but more succinct.
queryNot(subject("hello"))
  |> orAll([flags(Unseen), older(3600)])

I think this is probably OK. I wonder about namespacing these functions though? They'll be in the imap module but then should each of these have a pseudo namespace prefix, so we're using querySubject(), queryFlags(), queryOrAll(), etc.?

@Laeeth @John-Colvin @rmanthorpe @skoppe

[John-Colvin]

Could make them members instead of free functions

[otrho]

Fixed with #61 though may need some more refinement, and see #62 for further functionality.