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