Skip site navigation (1) Skip section navigation (2)

Re: JAVA Support

From: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Josh Berkus" <josh(at)agliodbs(dot)com>, "Kris Jurka" <books(at)ejurka(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JAVA Support
Date: 2006-09-29 16:01:32
Message-ID: 55F9BF0B-D909-4ABC-BA76-D75A52392C05@jpl.nasa.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sep 29, 2006, at 12:31 AM, Magnus Hagander wrote:

>>> However, that doesn't change that some people would like us to
>> support
>>> GSSAPI, and there may be some benefit (additional applications,
>> better
>>> network authentication, etc.) for doing so.  If we can get
>> additional
>>> programmers to code the support (i.e. Sun, JPL) I don't see any
>> reason
>>> 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.
>
> Oh, absolutely.
>
>
>> 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.

Probably save some Kerberos bookkeeping.  Probably loose it with  
GSSAPI bookkeeping, including name translation (which is far less  
obvious).  Net, I would expect to lose, but not by very much.

>> What amount of code are we talking about adding here, and what
>> dependencies exactly?  What portability and license hazards will be
>> added?
>
> 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.
>
> //Magnus

If I had a lot of time to spend on this I would write a SASL-like  
wrapper so it could be used on platforms with GSSAPI, but not SASL  
support in the OS.  As you may have noticed, I believe SASL is the  
way to go.  I'm not up for it though.

There's probably room in the world for a "SASL-lite" library though.   
Cyrus is great, but if your OS doesn't supply it for you, it's  
supposed to be really hard to build.


------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu



In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-09-29 16:14:11
Subject: Array assignment behavior (was Re: Stored procedure array limits)
Previous:From: Tom LaneDate: 2006-09-29 15:57:39
Subject: Re: Block B-Tree concept

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group