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 _______________________________________________ notmuch mailing list email@example.com https://notmuchmail.org/mailman/listinfo/notmuch