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