From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tomi.ollila@iki.fi>
Received: from localhost (localhost [127.0.0.1])
 by arlo.cworth.org (Postfix) with ESMTP id 1EC106DE0C3B
 for <notmuch@notmuchmail.org>; Tue, 12 Nov 2019 15:30:58 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at cworth.org
X-Spam-Flag: NO
X-Spam-Score: 0.402
X-Spam-Level: 
X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[AWL=-0.250, 
 SPF_NEUTRAL=0.652] autolearn=disabled
Received: from arlo.cworth.org ([127.0.0.1])
 by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id C7Xn8855tVC8 for <notmuch@notmuchmail.org>;
 Tue, 12 Nov 2019 15:30:56 -0800 (PST)
Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])
 by arlo.cworth.org (Postfix) with ESMTP id 5C63E6DE0B36
 for <notmuch@notmuchmail.org>; Tue, 12 Nov 2019 15:30:55 -0800 (PST)
Received: from guru.guru-group.fi (localhost [IPv6:::1])
 by guru.guru-group.fi (Postfix) with ESMTP id E41CB1000B0
 for <notmuch@notmuchmail.org>; Wed, 13 Nov 2019 01:30:50 +0200 (EET)
From: Tomi Ollila <tomi.ollila@iki.fi>
To: notmuch@notmuchmail.org
Subject: Re: [PATCH] Add --message-headers flag to notmuch-show
In-Reply-To: <87a790pwke.fsf@fifthhorseman.net>
References: <20191110124929.21903-1-johan.parin@gmail.com>
 <874kzatox1.fsf@fifthhorseman.net> <87y2wms9r4.fsf@fifthhorseman.net>
 <m2imnokieb.fsf@gmail.com> <87a790pwke.fsf@fifthhorseman.net>
User-Agent: Notmuch/0.28.3+84~g41389bb (https://notmuchmail.org) Emacs/25.2.1
 (x86_64-unknown-linux-gnu)
X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL
 $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F
 !)g;OY^,BjTbr)Np:%c_o'jj,Z
Date: Wed, 13 Nov 2019 01:30:50 +0200
Message-ID: <m2sgmshdud.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: notmuch@notmuchmail.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Use and development of the notmuch mail system."
 <notmuch.notmuchmail.org>
List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,
 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch/>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,
 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 23:30:58 -0000

On Tue, Nov 12 2019, Daniel Kahn Gillmor wrote:

>
> And, I still haven't heard any clear arguments for choosing between
> configurability as an absolute thing or a differential thing.  They have
> significantly different impact on adopters over time, as the default
> configuration changes.

I don't understand your question, but I think that configuration option
for choosing what message headers to return is far worst of the options,
mostly because configuration and what frontend may desire goes easily
out if sync (and when managed manually that is what inevitably will
happen). 

> So, of the three options you list, i far prefer (a) because it doesn't
> introduce any of the configurability maintenance or API complexity
> costs.

> If the main objection to (a) is performance regression, i'd like to see
> some profiling of that performance cost, so we can better understand it.
> Perhaps there's a different way to mitigate a performance regression.

I'd guess it depends how frontends spend time parsing json/sexp output. 
I would not expect raw C code to be bottleneck, don't know how gmime
spends time fetching header data on user request...

The option (b) is kinda my favorite, code could be pretty simple, ordering
(sprinted in order listed), duplicates (rescan request list so far and drop
if header found) might be the harders questions (and seemed not ;/). 

If option (b) were taken, status quo -- no change in returned headers
should be maintained -- separate patch series w/ devel/schemata and test
changes can be sent is there desire for changing that.


>
>           --dkg

Tomi