<br><br>On Sunday, January 22, 2017, Cory Benfield <<a href="mailto:cory@lukasa.co.uk">cory@lukasa.co.uk</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 22 Jan 2017, at 17:01, Wes Turner <<a href="javascript:_e(%7B%7D,'cvml','wes.turner@gmail.com');" target="_blank">wes.turner@gmail.com</a>> wrote:</div><div><br><div>- OpenSSL 1.1.0 supports DANE </div><div>- GnuTLS supports DANE</div><div>- AFAIU, neither SChannel nor Secure Transport yet support DANE</div><div><br></div><div>So, in order to support e.g. DANE, where would the additional backend-specific configuration occur?</div></div></blockquote><div><br></div><div>This would be up to the individual specific backends. They are allowed to extend the API provided here in whatever manner they see fit.</div><br><blockquote type="cite"><div>A frozen ordered dict would be preferable because:</div><div><br></div><div>- Inevitable eventuality of new/additional config parameters</div><div>- Consistency and readability of API access with [], .__getitem__(), .get()</div><div>- <a href="https://www.python.org/dev/peps/pep-0416/#rejection-notice" target="_blank">https://www.python.org/dev/<wbr>peps/pep-0416/#rejection-<wbr>notice</a> ... </div><div>- <a href="https://docs.python.org/3.5/library/types.html#types.MappingProxyType" target="_blank">https://docs.python.org/3.5/<wbr>library/types.html#types.<wbr>MappingProxyType</a></div><div><br></div><div>NamedTuple is preferable because:</div><div><br></div><div>- Immutability</div><div>- Speed</div><div>- RAM</div></blockquote><div><br></div><div>So immutable types are key, and a truly-frozen ordered dict would be fine from that perspective.</div><div><br></div><div>However, the key reason I want to use a namedtuple instead of a dict is to discourage ad-hoc extension of the configuration type (with the side benefit of reducing the risk of typo-based configuration and implementation errors. Essentially, the dictionary approach encourages adding ad-hoc keys into the configuration, which *reduces* auditability and encourages the proliferation of essentially implementation-specific keys.</div></div></div></blockquote><div><br></div><div>So then there are two ways to preserve the centralized configuration (with a configuration object):</div><div><br></div><div>1. extra_config, a TLSConfiguration parameter pointing to e.g. a (mutable) List or an OrderedDict of additional parameters</div><div>2. create an additional configuration object for additional configuration parameters</div><div><br></div><div>KeyErrors and AttributeErrors are indeed useful for catching configuration errors (in additional to the policy validation opportunity that a configuration object provides)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div>If defined, backed specific configuration settings could take precedence over platform-neutral defaults.</div></blockquote><div><br></div><div>So, that’s definitionally true. What’s very hard is coming up with a general way to express those backend-specific configuration settings, which is why I’m not really trying. In fact, it would probably be possible to argue that doing that is impossible.</div></div></div></blockquote><div><br></div><div>An Ordered of these backend-specific configuration parameters - while maybe not standardizable - could be helpful: cfg.backend_settings[BACKEND_ENUM] = Ordered the()</div><div><br></div><div>One use case is applications which don't/won't define any actual config code for their app; they just want it to work everywhere (which may mean working with each platform's native TLS library). There's then an external config to be read into TLSConfiguration (and whatever else for backend-specific configuration parameters)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>Cory </div></div><br></div></blockquote>