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:
>>>
>>> On 15.06.2012 17:39, Magnus Hagander wrote:
>>>>
>>>>
>>>> On Fri, Jun 15, 2012 at 6:48 PM, Florian Pflug<fgp@phlo.org> wrote:
>>>>>
>>>>>
>>>>> The way I see it, if we use SSL-based compression then non-libpq
>>>>> clients
>>>>>
>>>>> there's at least a chance of those clients being able to use it easily
>>>>> (if their SSL implementation supports it). If we go with a third-party
>>>>> compression method, they *all* need to add yet another dependency, or
>>>>> may
>>>>> even need to re-implement the compression method in their
>>>>> implementation
>>>>> language of choice.
>>>>
>>>>
>>>> I only partially agree. If there *is* no third party SSL libary that
>>>> does support it, then they're stuck reimplementing an *entire SSL
>>>> library*, which is surely many orders of magnitude more work, and
>>>> suddenly steps into writing encryption code which is a lot more
>>>> sensitive.
>>>
>>>
>>> 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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
