On 13 January 2017 at 19:33, Nathaniel Smith <n...@pobox.com> wrote:
> On Fri, Jan 13, 2017 at 1:09 AM, Cory Benfield <c...@lukasa.co.uk> wrote:
> I get what you're saying about a typed API -- basically in the current
> setup, the way _BaseContext is written as a bunch of Python methods
> means that the interpreter will automatically catch if someone tries
> to call set_cihpers, whereas in the dict version each implementation
> would have to catch this itself. But in practice this difference seems
> really minimal to me -- either way it's a runtime check

The difference isn't minimal at all from the perspective of:

- static type analysis
- runtime introspection
- IDEs (which use a mixture of both)
- documentation

Config dictionary based APIs have *major* problems in all those
respects, as they're ultimately just a bunch of opaque-to-the-compiler
keys and values.

Network security is a sufficiently hard problem that we want to make
it as easy as possible for developers to bring additional tools for
ensuring code correctness to bear :)

> and it's
> really difficult to write a loop like
>   for key, value in config.items():
>       do_some_quirky_cffi_thing_based_on_key()
> that doesn't implicitly validate the keys anyway. There's also the
> option of using e.g. JSON-Schema to write down a formal description of
> what goes in the dict -- this could actually be substantially stricter
> than what Python gets you, because you can actually statically enforce
> that validate_certificates is a bool. For whatever that's worth --
> probably not much.

I've generally found that it's easier to build a declarative API atop
a programmatic API than it is to tackle a problem the other way

1. Even if the only public API is declarative, there's going to be a
programmatic API that implements the actual processing of the
declarative requests
2. Working with the programmatic API provides insight into which
features the declarative API should cover, and which it can skip
3. Programmatic APIs are often easier to test, since you can more
readily isolate the effects of the individual operations
4. A public programmatic API serves as a natural constraint and test
case for any subsequent declarative API


Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
Security-SIG mailing list

Reply via email to