> > However, that doesn't change that some people would like us to
> > GSSAPI, and there may be some benefit (additional applications,
> > network authentication, etc.) for doing so. If we can get
> > programmers to code the support (i.e. Sun, JPL) I don't see any
> > not to support the *additional* authentication methods.
> Well, as I said already, a lot depends on the size of the patch.
> As a reductio ad absurdum, if they drop 100K lines of code on us,
> it *will* get rejected, no matter how cool it is.
> The current Kerberos support seems to require about 50 lines in
> configure.in and circa 200 lines of C code in each of the backend
> and libpq. Plus a dependency on an outside library that happens to
> be readily available and compatibly licensed.
I would expect, without looking at the details of the API, GSSAPI to be
about the same amount of code if not less.
> What amount of code are we talking about adding here, and what
> dependencies exactly? What portability and license hazards will be
The Kerberos5 libraries that we rely on today provide GSSAPI. So it
would work with the same external library. Now, it could *also* work
with other libraries in some cases (for example, the Win32 SSPI
libraries), but with the same libraries it should work fine.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly