Re: [PATCH] Add --message-headers flag to notmuch-show

[Tomi Ollila <tomi.ollila@iki.fi>]

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