Re: JAVA Support

> > As for the other part - will core accept this - I can't
> answer that. I
> > do beleive that there is a point to it, given that Java will then
> > support it natively, but I'm not core. I'm unsure if there
> is a clear
> > view on the merits of adding more authentication options..
>
> From the lack of traffic on this list I gather that the core
> developers no longer hang out here. I've been gone for a few years.

Oh, they most definitly do. Every one of them. They just don't write in
every single thread (though sometimes I wonder about Tom..)

I noticed you copied Tom Lockhart - he isn't core anymore, so don't
expect a response there. Tom Lane is, though, and I'm sure he'll
respond.

> For the record here's the arguments:
<snip a bunch of SASL arguments that I'm sure are perfectly valid>

> f) SASL support is available in current Java as well as C.
> SASL libraries are included (or at least loadable) on MacOS,
> Solaris 10+, and Linux. (I don't do windows, so I can't say
> there.) While it has a reputation for complexity, that
> complexity is in building the libraries, not in using them.
>
> It can be used to provide most (all?) of the functionality
> now provided by the assortment of existing mechanisms.

Well, it's still a complexity you need to deal with. Plus, just Java and
C is far from enough, if you are intending to suggest we replace some of
what we have now with it (like passwords and other such things). For
example, you need things like perl, python, ruby, C#, etc etc. not sure
how many of those would be fine with a C wrapper, I know for a fact that
C# (or other .net languages) wouldn't, they need it natively.

There also used to be some bad portability issues wrt at least some of
the SASL libraries (if there is more than one). I know I tried to make
it work on win32 once and failed miserably. (Then again, I've failed on
Linux as well, but not quite as bad. And it's not included in all Linux
distributions, at least it wasn't when I checked a while back)

And finally, there's backwards compatibility. We're still going to have
to support all the existing ones for the forseeable future unless you
want to prevent all older clients from connecting (hint: you don't).

> If provided as an alternative, it could eventually allow
> decommissioning of a lot of the other mechanisms. If the
> number of existing mechanisms is an issue, then this could be
> a big long-term win.

Me, I think providing it as an alternative is the path to go. Which also
means that I think implementing GSSAPI for that (probably in long-term
to *replace* our current Kerberos authentication, in short-term to
complement it) rather than SASL, because it's significantly simpler.

> I'll assume the ball is in my court now, unless someone wants
> to claim I should just do GSSAPI and not bother with the higher level.

That would be my suggestion - do GSSAPI only and leave the current
methods the way they are. This should be doable without a huge amount of
code, and without affecting the other well-working mechanisms.

//Magnus