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?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
