This vote has another 15 hours to run. I'm personally -0 for adopting this module at all, it seems to run afoul of some design considerations that have excluded other modules in the past, such as mod_macro, from becoming part of httpd. That there are multiple static resources to be presented as single static resources seems computationally intensive and not the core webserver's task to handle, and an excuse for poor site and app design.
I would join Jim in supporting mod_combine as a subproject, external to httpd trunk, for now. In the absence of additional support for this module this second time around, I'm stronly -1 to add this to httpd trunk on some lazy consensus. New modules should not hit httpd trunk without clear support from multiple, active project members. So for now my vote is option 2 as a show of support of Graham, to let him demonstrate that this fits in httpd. I guess the same could be said for a sandbox; we are all welcome to create a sandbox at any time without any vote at all. I'd rather that mod_combine be given recognition as a proper subproject > [X] Option 2: adopt only as subproject On 3/3/2012 9:08 AM, William A. Rowe Jr. wrote: > A proposal to adopt mod_combine is attached. > > [ ] Option 1: adopt as trunk module > [ ] Option 2: adopt only as subproject > [ ] Option 3: do not adopt > > > > [Prior to this vote, this proposal had not passed; jim alone had joined > minfrin in supporting the proposal. Please take another look and vote.] > > On 12/13/2011 12:27 PM, Graham Leggett wrote: >> Hi all, >> >> As with mod_firehose and mod_policy, I have concluded negotiation with the >> BBC to open source some httpd modules that I wrote under the AL, and the BBC >> have very kindly agreed to donate the code to the ASF[1], which I believe >> would fit well as a subproject of httpd, and would like to know whether >> httpd would accept these. >> >> To be clear, this isn't a "code dump", my intention is to continue to >> develop and support this moving forward, and hopefully expand the community >> around them. >> >> - mod_combine: "Response concatenation" >> >> As a page gets more complex, and eventually parts of the page like the >> header and footer become maintained by separate teams, the elements that >> make up a page can become fragmented. In the process, you can end up with a >> page that takes ages to load, because lots of fragments of javascript or >> fragments of CSS files are being downloaded separately by the browser. >> >> mod_combine is a handler that allows multiple URLs hosted by the server to >> be concatenated together and delivered as a single response, cutting down on >> the number of requests, and in turn the page loading time. >> >> At the same time, mod_combine attempts to behave sensibly when one or more >> of the files is missing, so as not to amplify a failure. The handler also >> properly supports conditional requests, creating a "super ETag", and then >> reversing it to apply conditional requests on each element being >> concatenated. >> >> The code is currently packaged as an RPM, wrapped in autotools, and a >> snapshot is available here: >> >> http://people.apache.org/~minfrin/bbc-donated/mod_combine/ >> >> The corresponding README documenting in more detail is here: >> >> http://people.apache.org/~minfrin/bbc-donated/mod_combine/README >> >> The code itself is here: >> >> http://people.apache.org/~minfrin/bbc-donated/mod_combine/mod_combine.c >> >> Obviously the expectation is for the documentation to be completed and >> fleshed out. >> >> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 >> >> Regards, >> Graham >> -- >> >> > >
