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.
best regards,
Florian Pflug