From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.0 required=3.0 tests=BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A16B41F453; Mon, 1 Oct 2018 07:46:20 +0000 (UTC) Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1g6suG-0007pk-Hy; Mon, 01 Oct 2018 09:46:16 +0200 Message-ID: <1538379966.3126.13.camel@sipsolutions.net> Subject: Re: IMAP server [was: Q: V2 format] From: Johannes Berg To: "Eric W. Biederman" Cc: Eric Wong , meta@public-inbox.org Date: Mon, 01 Oct 2018 09:46:06 +0200 In-Reply-To: <87zhw1cp5s.fsf@xmission.com> References: <87k1q1bky6.fsf@xmission.com> <20180712014715.dn5aouayoa3uejp4@dcvr> <87k1q07dyc.fsf@xmission.com> <20180712230946.mqv3yjw4aabf7xrf@dcvr.yhbt.net> <878t6f1ch7.fsf@xmission.com> <20180713230746.GA2680@dcvr> <1538165409.14416.92.camel@sipsolutions.net> <87zhw1cp5s.fsf@xmission.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 (3.26.6-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: On Fri, 2018-09-28 at 23:01 +0200, Eric W. Biederman wrote: > > I have looked at gnus and there is support in there for performing > searches via the old gmane web interface. Public inbox already provides > an attribute that tells you what the web server is. So all it will > really take is someone with a little time to wire up the search > interface. That's ... interesting, but of course completely out-of-band. I'm not sure it should or could be advocated that every email client actually implement that :-) But if you think broader than that, you don't even necessarily need a web server to run p-i. > Beyond that if you have the archives local (and that is easy) it is > quite possible to just git grep through them and find things of > interest. That also doesn't use the index, not sure how that's any better? > I should verify this but I don't think IMAP has a good version of the > NNTP overview database. Which seems to make IMAP quite a bit slower for > reading news. Certainly gnus+public-inbox locally is running quite a > bit faster than my old gnus+cyrus-imap configuration. IMAP servers typically should do header/MIME parsing, so you should be able to query such a thing - but not as easily as XOVER, I suppose. However, I think FETCH could be made to return the data similar to XOVER, though it may not be backed by a pre-created database file, and it depends on what the client does to show the overview in the first place. > I tried to read through the IMAP search specification to see how it > compares with what public-inbox makes available and I did not get > particularly far. It was not easy to match up the various search > capabilities. The biggest issue is that IMAP tends to not talk > about message-ids. Where that is fundamentally one of the most > important fields to index if you are dealing with threaded mail. You can search for arbitrary headers in search by using HEADER where the string is "contains", so you can use it for both Message-Id and References headers. > So long story short while I am not opposed to a read-only IMAP > configuration I think NNTP has much to recommend it. I do think we need > little things like SSL support for NNTP. Just to prevent inappropriate > access to traffic in flight. Sure. I'm not saying NNTP is bad, just saying that the choice of clients is rather limited. Also, posting isn't supported over NNTP, so if I had it all in my email client I could read in the public-inbox archive, and respond via normal email. > It won't be for a while yet but I have some scripts I need to push at > least to the public-inbox scripts directory that simplify the process > taking a single email address subscribing to email and sorting it out > into different public-inbox git archives. Currently I have every > mailling list I am subscribed to pushed into public-inbox. :-) johannes