Eric Wong <e...@yhbt.net> writes: > Eric Abrahamsen <e...@ericabrahamsen.net> wrote: >> Kyle Meyer <k...@kyleam.com> writes: >> >> > [ +cc Eric Wong, mostly to say thanks for all the work he puts into >> > public-inbox, which is the software behind these archives, but also so >> > that he can correct me if I misrepresent any capabilities of or plans >> > for public-inbox ] >> >> Thanks for this response, Kyle (and thanks for public-inbox, Eric)! > > you're welcome, both :> > >> You wouldn't really use one backend (nnweb) to provide search support >> for another (nntp). nnir can assign different search engines to >> different backends -- what a "search engine" boils down to is a function >> that accepts group search criteria, and returns groups and article >> numbers (and optional relevance scoring) for matching messages. So if >> public-inbox had some sort of an API that accepted a query and returned >> the above information in some sort of easily-digestible format, it >> wouldn't be hard to write a engine for it. Articles referenced in the >> search results would then be retrieved via NNTP, so the article numbers >> would need to correspond. > > Fwiw, I've been trying to avoid exposing NNTP article numbers in > the HTTP endpoint in favor of Message-IDs because serial numbers > aren't decentralization-friendly. Of course, sometimes > Message-IDs get reused, so public-inbox will return all messages > which match a particular Message-ID in those rare cases. > > Btw, POST with the "&x=m" query parameter already allows search > to return a gzipped mboxrd. > > And also what I just wrote about about JMAP/GraphQL in the other > message. > > A read-only IMAP server is also coming with search support, > and IMAP UIDs will be equivalent to NNTP article numbers.
Sounds like something in there is bound to work! IMAP might be best -- while it's certainly possible to do Message-ID<->article number lookups, that will slow Gnus down further, and it's already fairly slow. Thanks again, Eric
