On Mon, Apr 10, 2017 at 6:50 AM,  <j...@apache.org> wrote:
> Author: jim
> Date: Mon Apr 10 11:50:26 2017
> New Revision: 1790806
> URL: http://svn.apache.org/viewvc?rev=1790806&view=rev
> Log:
> With v0.60 of https://github.com/google/brotli released,
> this is now viable again.

Agreed this is no longer 'being worked' but is again proposed...

> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Mon Apr 10 11:50:26 2017
>                    protocol input, also seems unwise)
>        jailletc36: needs r1790457 but can be merged afterwards. No 
> functionnal change.
> -  [ New entried should be added at the START of the list ]
> -
> -  *) core: Disallow multiple Listen on the same IP:port when listener buckets
> -     are configured (ListenCoresBucketsRatio > 0), consistently with the 
> single
> -     bucket case (default), thus avoiding the leak of the corresponding 
> socket
> -     descriptors on graceful restart.
> -     trunk patch: http://svn.apache.org/r1789220
> -     2.4.x patch: trunk works (modulo CHANGES)
> -     +1: ylavic
> -
>    *) mod_brotli: Backport of mod_brotli filter
>       trunk patch: http://svn.apache.org/r1761714
>                    http://svn.apache.org/r1762512
>                    http://svn.apache.org/r1779699
>       2.4.x patch: http://home.apache.org/~jim/patches/brotli-2.4.patch
>       +1: jim, jorton,
> -     -1: wrowe (Premature, waiting on github.com/google/brotli 0.6 release)
> -     NOTE: Awaiting next release post 0.5.2

I was happy with the state of master as of Friday. I have not reviewed
the final release package, however.

I was very very happy with the huge documentation improvements
today. One key aspect I identified, that --deflate ++brotli is a net loss
for our examples, is unacceptable. Increasing the total traffic by ripping
out one universal compression method for a solution supported by only
half of the clients is, I'm sure you agree, a joke. Brotli can only be added
as a supplemental compression scheme in addition to gzip for older
clients at this time, particularly since the introduction of this compression
adds a large incremental cpu tax on the server.

I was disappointed to learn from the docs that input compression is not
even supported by the proposed enhancement. The browser clients
may not support it, but obviously other significant clients such as svn
should be adding it promply, the cpu cost to the clients pushing data
is not our worry at all, and the cpu cost of httpd decoding the brotli
compression is hardly measurable if not an actual win.

I'm amused by your rejection of my completing code review of this
submission, Jim. Classy.

Reply via email to