On Jan 12, 2007, at 11:55 PM, Howard Chu wrote:
Henry B. Hotz wrote:
On Jan 11, 2007, at 3:22 PM, Howard Chu wrote:
For a number of reasons (anyone following the embrace/extend/
extinguish testimony on groklaw?) even when a native Windows API
exists, we've chosen to only support portable APIs if the
parallel exists. Thus, our Windows builds of software use Cyrus
libsasl and OpenSSL, not Windows SSPI. We use OpenLDAP's libldap,
not the we- claim-it's-LDAP-honest API that Windows provides. In
general I think this is the wiser course of action because it
lessens our support burden, among other things.
Doesn't that make it harder to build your products?
Once, maybe. But it's a sunk cost we invested into our build system
7 years ago. In the end it makes support easier.
[. . .]
I have no interest in long-term maintenance; that's not how *I* make
my living. Whatever I do should be stable enough to survive without
me. That means its dependencies need to be on things that are
stable, and actively supported elsewhere. "Support" for me, means
someone else will support it if I build it and walk away.
I'm not sure if any of this directly addresses the question of how to
provide SASL support on Windows. I can't see PostgreSQL being happy
adding a capability that doesn't work on Windows. If someone were
willing to build against KfW, then they could build the existing Krb5
support on Windows. PostgreSQL already has a rich selection of
authentication methods, so their incremental gain isn't what you
might expect from adoption of SASL.
My specific motivation is to provide an auth method that supports
Kerberos in the Java client. I would still get that, but it's
looking like I don't get as much beyond that as I hoped for.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx
