user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Eric Wong <>
Subject: IMAP server notes, maybe JMAP?
Date: Tue, 9 Jun 2020 11:34:42 +0000	[thread overview]
Message-ID: <20200609113442.GA16856@dcvr> (raw)

OK, so I almost have something that won't kill clients or
trigger OOMs on the server.  I think I'll have to implement MSN
(message sequence numbers) properly for some clients, cheaply.

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] - (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? :)

Anyways, the IMAP server is based on the existing NNTP server
code; but also provides a fresh place to test new ideas for
improving scalability and performance:

* It's fair to other clients if using slow blob storage,
  and I've gotten to be fairly happy with the API.  Slow
  Xapian storage isn't accounted for, yet, but will be.
  Aggressive pipelining in mbsync(1) helped me get async
  bugs ironed out.

* LIST wildcard matching/globbing tested with 100K inboxes,
  other pieces still need work.

* Incremental config reloading on SIGHUP works, but
  could be more granular.

* IMAP IDLE supported for EXISTS (but not EXPUNGE for spam).

* Inotify (or EVFILT_VNODE) used for IMAP IDLE notifications.
  More inotify/EVFILT_VNODE usage to come for manifest.js.gz
  updates, git-cat-file restarts, DB reopens, etc.  I've used
  inotify a bunch in the past, but not in Perl.  This is my
  first time with EVFILT_VNODE, but inotify seems more capable.

* --reindex is recommended for the RFC822.SIZE fetch
  attribute to account for CRLF conversion.  Actually,
  we've been wrong about NNTP :bytes reporting for years,
  too, but IMAP clients (at least Mail::IMAPClient) actually

* Common cases of Xapian search work, but also require
  --reindex.  Reindex is doable while serving, results just
  won't show until reindexed.

* COMPRESS, STARTTLS, TLS are all inherited from -nntpd

* PublicInbox::Eml can descend in to message/* subparts
  properly, which makes it possible to implement stuff
  like BODYSTRUCTURE properly.  And who uses BODYSTRUCTURE?

And a note:

* Don't create 100K public-inboxes in the worktree itself,
  MakeMaker looks inside all directories when doing
  "perl Makefile.PL" :x


* 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.

* IMAP extensions are worth looking into, especially ones
  around search.  Some of them look interesting w.r.t. search,
  along with overlap with JMAP.

* There's also thread-related stuff and that may be able to
  implement "Search based on data in follow-ups"

* An "All Mail" mailbox could be cool for IMAP/JMAP search
  (it's planned for HTTP, anyways)

I hit numerous bugs in 3rd-party libraries while working
on the server, all of them involving around compression:

* Python imaplib2 (via offlineimap)

  - compress timeout:

* Mail::IMAPClient

  - compress reference cycle:

  - compress read starvation:

* Compress::Raw::Zlib

  - inflate appending to OOK scalars
    mbsync(1) helped me expose this bug

Both Mail::IMAPClient and Mail::IMAPTalk do weird sleeps with
select(2) and SSL; maybe as a holdover from the days when

headaches for dealing with MUAs:

* Inboxes are split into 50K slices to avoid overloading MUAs.

  The word "slice" was not previously used in our codebase.
  Conceptually, it's like v2 "epochs".  Epochs are to deal
  with the limitations of git clients, slices are to deal
  with the limitations of IMAP clients.

* HEADER.FIELDS retrieval still requires taking the whole
  blob from git.  Clients can request any header(s) they
  wish; unlike NNTP, where the server defines the overview.
  I've managed to speed this up significantly with a little
  pure-Perl opcode compiler, though :)

* MSNs (message sequence numbers) seem required to get decent
  performance from mutt and maybe other MUAs.  Showing fake
  dummy messages for removed spam is poor UX, too...

             reply	other threads:[~2020-06-09 11:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-09 11:34 Eric Wong [this message]
2020-06-15  6:21 ` Parse::RecDescent dependency (was: IMAP server notes, maybe JMAP?) Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200609113442.GA16856@dcvr \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).