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. -- unsubscribe: one-click, see List-Unsubscribe header archive: https://public-inbox.org/meta/
