Funny you mention it. Nginx had it first anyways, and was (perhaps still is) using the deprecated API that dies with libbrotli rev 1.0.0 - part of that delay might have been affording ngnix a chance to adapt. Versioning their installed library should allow both to be installed at once.
So... providing our users enough info to actually use the module is worth hardly a nickle? 95c to win an undocumented feature on a bullet list? Providing no documentation to enable it isn't a failure by httpd? Whatever indeed. gzip and brotli, head to head at compression level 5, % cpu load increase is generally larger than the % bytes saved. brotli becomes much more interesting at much higher pre-compression values, with a corresponding savings in cpu due to fewer bytes read/transmitted. On Feb 16, 2017 13:56, "Jim Jagielski" <[email protected]> wrote: Whatever... nginx will have it 1st anyway. And once again we fail our users by having a nickel holding up a dollar. > On Feb 16, 2017, at 2:48 PM, William A Rowe Jr <[email protected]> wrote: > > On Thu, Feb 16, 2017 at 12:47 PM, Jim Jagielski <[email protected]> wrote: >> >>> On Feb 16, 2017, at 1:15 PM, William A Rowe Jr <[email protected]> wrote: >>> >>> >>> I concur with Evgeny Kotkov that an ABI stable dependency is appropriate >>> before adding this to httpd 2.4.x - so far as I've read none have suggested >>> this as an experimental addition to 2.4. >> >> I do. We release it w/ the caveat that it is dependent on a >> library that may change. Until that happens, we have users able >> to use Brotli. That is a Good Thing IMO. > > Let's examine your claim. There is no documentation at all of where to > find brotli. http://brotli.org/ is now one day old (congrats!!!) - but not yet > exactly discoverable, http://lmgtfy.com/?q=brotli+package > > The package lives now in Debian stretch and sid. Archlinux packages > seem out-of-sync. This only exists on Fedora as copr package so far. > So without telling users where to find it, "users able to use Brotli" is a > false statement. > > OS distributors are waiting for 1.0.0 to package this. What's our rush? > >> Re: the docs, seem a minor nit to hold back, esp when you >> don't even quantify how the docs are a complete mess nor the >> requirement for an example in docs/conf. What other requirements >> will you be spinning up? > > Missing 1. where to find brotli? 2. working config examples? These > points might seem counter-intuitive, but without such simple things, > the code is just dead weight. > > I'm investigating the interaction between brotli and deflate so we can > support both simultaniously before feeding it to our stable users. Halting > compression for half of the browsers in order to win a small percentage > gain for the other half of the browsers seems sub-optimal, no? > > I'll be glad to discover that the brotli and deflate filters already coexist > peacefully without double-compressing.
