* Andres Freund (andres@2ndquadrant.com) wrote:
> On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
> > At first blush, I'd say a whole bunch.. Off the top of my head I can
> > think of:
[...]
> I'm not really sure we need all that. We're not building a general ssl
> library abstraction here.
Really? I'm pretty sure that's exactly what we're doing. What I was
wondering is which one we should be modeling off of.
One thought I had was to look at what Apache's mod_ssl provides, which
can be seen here: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
I know that I've used quite a few of those.
Telling users they simply can't have this information isn't acceptable.
I'm not a huge fan of just passing back all of the certificates and
making the user extract out the information themselves, but if it comes
down to it then that's at least better than removing any ability to get
at that information.
> What I'm wondering is whether we should differentiate 'standard'
> attributes that we require from ones that a library can supply
> optionally. If we don't we'll have difficulty enlarging the 'standard'
> set over time.
If we end up not being able to provide everything for all of the
libraries we support then perhaps we can document which are available
from all of them, but I'd hope the list of "only in X" is pretty small.
Thanks,
Stephen
