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=-3.8 required=3.0 tests=ALL_TRUSTED,AWL,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 2EE6B1F4B4;
	Thu, 10 Dec 2020 00:41:58 +0000 (UTC)
Date: Thu, 10 Dec 2020 00:41:58 +0000
From: Eric Wong <e@80x24.org>
To: meta@public-inbox.org
Subject: One, All; Some? [was: isearch: per-inbox search using ->ALL]
Message-ID: <20201210004158.GA7895@dcvr>
References: <20201205101138.11973-1-e@80x24.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20201205101138.11973-1-e@80x24.org>
List-Id: <meta.public-inbox.org>

Eric Wong <e@80x24.org> wrote:
> Now, if extindex.all.topdir is configured, per-Inbox Xapian
> search will use ->ALL, and not xap15/[0-9] (over.sqlite3 is
> still required for each inbox).

Just putting down some thoughts down:

This is done:

	[extindex "all"]	-> all (obviously)
		isearch		-> one


This is somewhere in the distant horizon:

		???		-> some (2+ inboxes, but not all of them)

> Unfortunately, IMAP still needs much work and still uses per-inbox
> Xapian indices.
> 
> Not sure about JMAP, but it looks like it'll be supportable
> since we won't have to worry about MSN<=>UID mappings and
> limiting mailbox size to accomodate (non-existent :P) MUA support

isearch was simple because we can use `num' directly from the per-inbox
over.sqlite3 DB.

For combining 2+ inboxes together ("???"), there still needs to
be a new over.sqlite3 file which provides IMAP UIDs.  Of course
Xapian is the storage hog, so "???" will use what's already in
"all" and not its own Xapian index.