Euler Taveira <euler@timbira.com> writes:
> I see the point in not adding another dependencies or reinventing the wheel
> but I see more drawbacks than benefits in adopting a SSL-based compression.
In the end, judging this tradeoff is a matter of opinion, but I come to
the opposite conclusion. Transport-level compression is not part of the
core competence of this project. As such, if we have an opportunity to
farm out that work to other projects (particularly ones that we are
already relying on), we should do so. Not expend our limited resources
on re-inventing this wheel, which we'd be more likely than not to do so
less well than it's already been done.
To draw an analogy: on the basis of the arguments that have been made
about how some users might not have access to an SSL library
implementing feature X, we should drop our use of OpenSSL entirely and
re-implement transport encryption from scratch, incompatibly with OpenSSL.
Now that's obviously ridiculous, not least because it does nothing at
all to ease the pain of people who need a non-C implementation. But
arguing that we should not use OpenSSL's compression features because
some people might need to use a different SSL implementation doesn't
seem to me to be any different from that.
regards, tom lane
