httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: [RE-VOTE #3] adoption of mod_combine subproject
Date Mon, 05 Mar 2012 18:14:31 GMT
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
>> --
>>
>>
> 
> 


Mime
View raw message