On Fri, Jun 15, 2012 at 5:48 AM, Florian Pflug <fgp@phlo.org> wrote:
> On Jun15, 2012, at 12:09 , Magnus Hagander wrote:
>> On Fri, Jun 15, 2012 at 5:52 PM, Florian Pflug <fgp@phlo.org> wrote:
>>> On Jun15, 2012, at 07:50 , Magnus Hagander wrote:
>>>> Second, we also have things like the JDBC driver and the .Net driver
>>>> that don't use libpq. the JDBC driver uses the native java ssl
>>>> support, AFAIK. Does that one support the compression, and does it
>>>> support controlling it?
>>>
>>> Java uses pluggable providers with standardized interfaces for most
>>> things related to encryption. SSL support is provided by JSSE
>>> (Java Secure Socket Extension). The JSSE implementation included with
>>> the oracle JRE doesn't seem to support compression according to the
>>> wikipedia page quoted above. But chances are that there exists an
>>> alternative implementation which does.
>>
>> Yeah, but that alone is IMO a rather big blocker for claiming that
>> this is the only way to do it :( And I think the fact that that
>> wikipedia page doesn't list any other ones, is a sign that there might
>> not be a lot of other choices out there in reality - expecially not
>> opensource…
>
> Hm, but things get even harder for the JDBC and .NET folks if we go
> with a third-party compression method. Or would we require that the
> existence of a free Java (and maybe .NET) implementation of such a
> method would be an absolute must?
>
> 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.
hm, that's a really excellent point.
merlin