Hi Willy,
Thank you for your reply.
The time schedule is not yet set, but I believe we will require one/two
months as this is not high priority on our side at the moment.
Since we have confirmed that merging is indeed promising (depending on
the quality of the patches), I can give the green light to start working
on this.
Thank you also for your points, we will have a more thorough look into
the code and we will get back to you in the near future with questions
etc :)
Cheers,
Vasilis
On 27/05/17 08:09, Willy Tarreau wrote:
Hi,
On Fri, May 26, 2017 at 06:57:14PM +0200, Aleksandar Lazic wrote:
Hi Vasileios Kyrillidis.
Vasileios Kyrillidis <[email protected]> have
written on Fri, 26 May 2017 16:17:48 +0200:
Hi Aleksandar,
No patches yet. We wanted confirmation that it has a chance of
getting merged before spending the time implementing. We have other
solutions that we could pursue instead.
If merging looks promising we will start working on patches.
Well I'm not a decision guy but when the patche's look good and does
match the event based system of haproxy I think there a good chances to
be part of haproxy.
It could be interesting, and theorically possible using the filters (ie
do the opposite of the compression). However you'll face some painful
difficulties : while with compression it's trivial to ensure that an
output chunk will never be larger than the input one, you can't do that
with decompression as just a few bytes can decompress into thousands.
This will require to keep some large memory contexts allocated, except
that contrary to the compression it will not even be possible to limit
this and decide not to decompress.
Another point is that usually for compression we build with USE_SLZ, which
doesn't provide decompression so you'll either need to make this feature
dependant on USE_ZLIB only or ensure it's disabled when using USE_SLZ.
Finally, please be aware that we're not merging new features for 1.8 now
so if you do this, it will be for 1.9. But if you have some good quality
patches ready in time, I'm fine with opening a "next" branch to accumulate
all the pending work for when 1.9-dev opens.
Cheers,
Willy
--
*Vasileios Kyrillidis* | Software Developer | Sociomantic Labs
www.sociomantic.com
<https://www.sociomantic.com/?utm_source=sociomantic&utm_medium=email&utm_campaign=signature-homepage> |
Twitter <http://www.twitter.com/sociomantic> + Facebook
<http://www.facebook.com/sociomantic> + Resources
<http://blog.sociomantic.com/?utm_source=sociomantic&utm_medium=email&utm_campaign=signature-resources> |
*Subscribe* to our Newsletter
<https://www.sociomantic.com/newsletter?utm_source=sociomantic&utm_medium=email&utm_campaign=signature-newsletter>.
Sociomantic Labs Logo
Sociomantic Labs GmbH, Location: Berlin, Commercial Register - AG
Charlottenburg: HRB 121302 B, VAT No. - USt-ID: DE 266262100, Managing
Directors: Thomas Nicolai, Sarah McCarthy, Mark Anthony Hinds. This
message and any attachments are confidential and intended solely for the
use of the individual to whom it is addressed.
