Stephen Frost wrote:
>>Also, do we really want to import the NSPR into Postgres? I suspect not.
>>Of course, the only thing that people are tripping over license-wise is
>>libpq. But I think we would want to keep that as lean and mean as
>>possible, too.
>>
>>
>
>erm, I'm not really sure what you're saying here but perhaps I can
>clarify: I wasn't suggesting to add any serious amount of source code
>to PostgreSQL - NSS would be used just as OpenSSL is today, and as
>GNUTLS support was proposed, a seperate library which is distributed
>independently of PostgreSQL but can be compiled against. I don't know
>
>
>
I suspect that Andrew was concerned about the dependency NSS has on NSPR.
NSS dates back to the days before universal support for threads and mutexes.
NSPR was (is) a library designed to abstract platform differences in
those areas,
and to provide its own implementations where none was available in the
OS (e.g.
old MacOS, 16-bit Windows). So for example if you want to open an SSL
connection
using NSS you get to hand it an NSPR socket handle, not an OS socket
(however,
there are functions that allow construction of one from the other). For
an application
that has otherwise no need for cross-platform service abstraction, or
that has already
solved the problems NSPR solves in a different way, NSPR looks
like a big ball of goo that you don't need. NSS can't exist in an
application without NSPR.
Having said that, except in the case of cooperative threading
environments (do those
exist today??), there's no requirement on the application to actually
use NSPR for
anything other than plumbing underneath NSS.
Applications that want to handle their own I/O underneath the SSL library
(particularly useful in servers) will often not be happy with NSS due to its
layering above NSPR I/O.