Date: Fri, 15 Jun 2012 11:58:55 -0400
From: Ryan Kelly <rpkelly22@gmail.com>
To: Magnus Hagander <magnus@hagander.net>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Florian Pflug <fgp@phlo.org>, Bruce Momjian <bruce@momjian.us>,
	Tom Lane <tgl@sss.pgh.pa.us>, Euler Taveira <euler@timbira.com>,
	Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq compression
Message-ID: <20120615155855.GD319@llserver.lakeliving.com>
References: <20120615021938.GA21704@momjian.us>
	<CABUevEyv4T+1gR6_Uqm_1qUD9PNDg6UdXbJhwHZgFi9hpQQ6NQ@mail.gmail.com>
	<F3B8BAA6-23E9-423A-A7D1-D2E14769F326@phlo.org>
	<CABUevExi-cJ6AvF2kDOy+qQsB+0JHofrcvVmNVoJ2HziZMMaAg@mail.gmail.com>
	<22690C61-E960-4A2A-BFD5-DAD3D3B5C474@phlo.org>
	<CABUevEzVpqS5RCLz2fFREdPFkuYkEKsrMpnfPixYWPki2=iJOA@mail.gmail.com>
	<4FDB4D0F.6090206@enterprisedb.com>
	<CABUevEyYgnO_zvQT2f8N2ZRZeZ-ZNeW4HxF9AAC3LJqRQrbWUg@mail.gmail.com>
	<4FDB5396.4050402@enterprisedb.com>
	<CABUevEwQeYE1MJGxV-kw5K0iTfaUtSE2r_6C0vZs5a_4CRHpww@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CABUevEwQeYE1MJGxV-kw5K0iTfaUtSE2r_6C0vZs5a_4CRHpww@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

On Fri, Jun 15, 2012 at 11:28:48PM +0800, 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:
> >>>
> >>> 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.
gnutls and openssl both support compression:

http://www.gnu.org/software/gnutls/manual/html_node/Compression-algorithms-used-in-the-record-layer.html
http://www.openssl.org/docs/apps/enc.html

-Ryan Kelly

> 
> -- 
>  Magnus Hagander
>  Me: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers