On Fri, Mar 05, 2021 at 10:20:19PM +0000, Eric Wong wrote: > 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.
\o/ > 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 don't really have any specific opinion on this matter. I don't really know of any other provider outside of Fastmail that uses JMAP, but it *is* a published IETF standard around RFC2822 messages, so it makes sense to use it for this purpose. > * lei saved searches can probably done quick for 1.7, > but without full keywords support for externals... I was wondering if lei should be part of the same suite as public-inbox proper as opposed to a standalone (or interdependent) client tool. Unless I'm mistaken, someone running a public-inbox origin or mirror server wouldn't necessarily be an active lei user. Decoupling them from each-other would allow different release cadence, no? > In any case, I need to take a few days away to clear my head. Please take care! Thanks for your effort on this project. Best, -K
