On Wed 2019-11-13 01:30:50 +0200, Tomi Ollila wrote: > 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,
configurability as an absolute thing:
--message-headers=foo,bar,baz
configurability as a differential thing:
--add-message-header=foo --suppress-message-header=qux
> 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).
totally agreed, but this is very different from what you said next:
> 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.
afaict, option (b) seems to contemplate configurability, which you say
above you don't want. Maybe we need a clearer list of options, because
this is getting confusing :P
--dkg
signature.asc
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
