From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_RED 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 9768B1F5AE; Mon, 26 Apr 2021 17:37:26 +0000 (UTC) Date: Mon, 26 Apr 2021 17:37:26 +0000 From: Eric Wong To: meta@public-inbox.org Subject: Re: lei-managed pseudo mailing lists Message-ID: <20210426173726.GA22986@dcvr> References: <20210426164454.5zd5kgugfhfwfkpo@nitro.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210426164454.5zd5kgugfhfwfkpo@nitro.local> List-Id: Konstantin Ryabitsev wrote: > Hello: > > One of the services I think would be interesting to provide is ability for > people to subscribe to "curated saved searches". For example, a kernel > subsystem maintainer can define a set of query parameters (a thread mentions > these files/functions/terms, etc), and allow others to follow this saved > search either by defining it as a remote source for their own lei command, or > by subscribing to it as they would to any regular mailing list. > > The latter is specifically something I think would be of interest to kernel > folks, so I envision that we'd have something like the following: > > - a maintainer publishes a configuration file we can pass to lei The command-line might be enough, the pathname of the current state/config file is a bit tricky and tied to its output. I suppose "lei import-search" can be a command, though... > - our backend lei process uses all of lore.kernel.org sources to create and > continuously update a new public-inbox repository with matching search > results There's already some accomodations for that in LeiSavedSearch which can present itself as a PublicInbox::Inbox-ish object to PublicInbox::WWW (untested). Searching an within LSS isn't implemented, yet, but I think it's doable w/o extra Xapian storage. However, git object storage isn't duplicated, which is nice for local use (instaweb-like), but supporting clone/fetch isn't as natural... Perhaps supporting a v2 inbox as an lei q output destination is in order: lei q --output v2publicinbox:/path/to/v2 --shared SEARCH_TERMS --shared would be "git clone --shared", the new v2 inbox can use ~/.cache/lei/all_locals_ever.git/ as an alternate and not duplicate space for blobs. > - we set up a mlmmj list that doesn't receive any direct mail but is only fed > from saved search results; people can subscribe/unsubscribe as they would > with any other mlmmj list > > Any particular reason this wouldn't work? Nope :) As long as all the data formats can interoperate (mostly RFC5322/2822). "lei convert" is nice, too :)