From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 9F40A1F9FD;
	Fri,  5 Mar 2021 22:20:19 +0000 (UTC)
Date: Fri, 5 Mar 2021 22:20:19 +0000
From: Eric Wong <e@80x24.org>
To: meta@public-inbox.org
Subject: release timelines (-extindex, JMAP, lei)
Message-ID: <20210305222019.GB1010@dcvr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
List-Id: <meta.public-inbox.org>

So I think the -extindex stuff might be stable and suitable for
general consumption.  The HTML WWW UI around -extindex has some
rough edges but nothing that would take too much effort to fix.

But I'm deeply worried about unleashing a new on-disk format
that's insufficient and being stuck supporting it forever
(as I am with v1 inboxes)...

* JMAP is going to be a more effort, but I think our current
  on-disk data model is OK or at least extensible enough for it.
  I might delay JMAP until 1.8.

  JMAP will be significantly less effort than inventing something
  new (and one-off) with GraphQL or REST.  And it would be less
  effort for client authors, as well; since client code can be
  used for non-public-inbox servers, too.

  I'm excited that it allows vendor extensions, which means our
  git-show|solver /$INBOX_URL/$OBJECT_ID/s/ blob-reconstruction
  endpoint can be exposed via JMAP.

* lei saved searches can probably done quick for 1.7,
  but without full keywords support for externals...

* Dealing with per-message keywords and externals in lei
  is going to be tough and delayed, I think:
  https://public-inbox.org/meta/20210224204950.GA2076@dcvr/
  ("lei: per-message keywords and externals")
  It may involve spinnning up a Python daemon to use
  custom PostingSource since Search::Xapian doesn't support it;
  and I don't expect anybody outside of FreeBSD to use SWIG Xapian.pm.

* lei has a bunch of rough edges and I'm not comfortable declaring
  it as supported, especially when there's a risk of data loss to
  users.

* .mailmap + Xapian synonym support would be nice in lei and
  HTTP/IMAP/JMAP endpoints

In any case, I need to take a few days away to clear my head.