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