Eric Wong <e...@yhbt.net> wrote:
> I know there's also interest in getting search usable via an
> HTTP(S) API, so maybe JMAP[1] is worth looking into since it
> seems like an easier-to-implement take on IMAP; and both
> have search. We already use JSON for manifest.js.gz...
>
> [1] https://lwn.net/Articles/680057/ - (a look at JMAP).
>
> GraphQL has also come up privately, but at a glance it seems to
> suffer some of the same problems with IMAP in offering excessive
> granularity and cache-unfriendliness. But anyways, I'm close
> to having a pretty good read-only IMAP server. JMAP cannot be
> any harder than IMAP right? :)
<snip>
> TODO:
>
> * Queries involving OR, NOT, and parentheses don't work, yet,
> since Xapian's default query parser works differently than
> the prefix (Polish) notation of IMAP.
So I've been giving Parse::RecDescent a try and it seems like an
acceptable dependency for IMAP (and possibly other) search query
parsing if we need it. It's widely-packaged by distros with
many dependents, including Inline::C and Mail::IMAPClient; so
it's likely already installed. I've been aware of it since
~2004 but it's my first time actually writing code to use it.
I also took a look at Regexp::Grammars, but it's unsupported on
Perl 5.18.[0-3] (I'm not sure if any distros package those versions)
and has fewer users.
Perl 5.10 regexps already support recursive descent with
(?<name>...) and (?&name) but it seems like a pain to use and
(?{ code }) behavior isn't very stable and IIRC a somewhat
common source of bugs in Perl itself.
I've also heard good things about Marpa, but it's not
packaged for CentOS 7.x and FreeBSD is missing the latest
release (or Debian is missing the stable release :x)
--
unsubscribe: one-click, see List-Unsubscribe header
archive: https://public-inbox.org/meta/
