Re: libpq compression

On Sat, Jun 16, 2012 at 12:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
>> On Sat, Jun 16, 2012 at 6:39 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> Fair enough if we decide that - but we should make that decision
>>> knowing that we're leaving the JDBC and .Net people in a bad position
>>> where they are not likely to be able to implement his.
>>>
>>> The JDBC people have a theoretical chance if the JDK is open. The .Net
>>> people are stuck with schannel that doesn't support it at this point.
>>> It might well do in the future (since it's in the standard); but
>>> they're at the mercy of Microsoft.
>
>> Both Java and C# are open-source enough that anybody can
>> take existing SSL implementation and add compression to it,
>> then distribute it as improved SSL library.
>
> Possibly more to the point: that is work they might have to do, if
> nobody else steps up to the plate --- and if they do end up doing it,
> it could benefit other projects too.  On the other hand, if we
> roll-our-own transport compression solution, that is work they *will*
> have to do, with no chance of sharing the effort with other projects.

True - provided said upstream (Oracle in the Java case) are interested
in accepting the patches...

If they end up having to port one of the compressoin algorithms, let's
dake LZ4 as an example, then they can certainly release that as open
source under a compatible license, thus making it available to others.

Though that's not necessarily that relevant - LZ4 already has a C#
implementation for .net, a JNI wrapper for Java.
Snappy even has a native Java implementation.

So if we went down that road, there wouldn't *be* a need to implement
it. Just the protocol parts itself, which are - compared to
implementing the actual compression in either scheme - trivial.

> BTW, as far as the .Net case goes, it took only a moment's googling
> to find this:
> http://openssl-net.sourceforge.net/
> which is a .Net wrapper around real OpenSSL.  It doesn't appear to
> provide wrappers for the compression selection functions, but surely
> that's just a lack of round tuits, not that it would take more than
> five minutes to add them.

that would then loose all the advantages that npgsql get from
schannel, such as integrated certificate management. So it can be done
- but it would AFAICT require a fairly large rearchitecture of how
security is handled, it would add a license-incompatible requirement,
and it would loose other features. But it can be done.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/