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?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com