On Sat, Jun 16, 2012 at 12:03 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 15.06.2012 18:28, Magnus Hagander wrote:
>>
>> On Fri, Jun 15, 2012 at 11:24 PM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>
>>> On 15.06.2012 17:58, Magnus Hagander wrote:
>>>>
>>>>
>>>> On Fri, Jun 15, 2012 at 10:56 PM, Heikki Linnakangas
>>>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>>>
>>>>>
>>>>> You could write a dummy SSL implementation that only does compression,
>>>>> not
>>>>> encryption. Ie. only support the 'null' encryption method. That should
>>>>> be
>>>>> about the same amount of work as writing an implementation of
>>>>> compression
>>>>> using whatever protocol we would decide to use for negotiating the
>>>>> compression.
>>>>
>>>>
>>>> Sure, but then what do you do if you actually want both?
>>>
>>>
>>> Umm, then you use a real SSL libray, not the dummy one?
>>
>>
>> But (in this scenario, and so far nobody has proven it to be wrong)
>> there exists no real SSL library that does support compression.
>
>
> Oh, I see. Then you're screwed. But I think the right solution to that is to
> write/extend a Java SSL implementation to support compression, not to invent
> our own in PostgreSQL. The JDK is open source nowadays.
I don't have any personal experience with it, but it's my
understanding that it's only opensource in the "published opensource
product" sense. Meaning it's not really something that solicits (or
even accepts? ast least not easily...) contributions from the outside.
And forgive me for being negative, but I think you're going to have an
even harder time to get Oracle to accept a contribution if the
motivation for having it is to make the PostgreSQL driver work
better...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/