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
