Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

[RE-VOTE #3] adoption of mod_combine subproject

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


wrowe at rowe-clan

Mar 3, 2012, 7:08 AM

Post #1 of 15 (491 views)
Permalink
[RE-VOTE #3] adoption of mod_combine subproject

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
> --
>
>


wrowe at rowe-clan

Mar 5, 2012, 10:14 AM

Post #2 of 15 (487 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

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
>> --
>>
>>
>
>


trawick at gmail

Mar 5, 2012, 10:29 AM

Post #3 of 15 (484 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

On Sat, Mar 3, 2012 at 10:08 AM, William A. Rowe Jr.
<wrowe [at] rowe-clan> wrote:
> A proposal to adopt mod_combine is attached.
>
>  [ ] Option 1: adopt as trunk module
>  [ ] Option 2: adopt only as subproject
[X] Option 3: do not adopt


minfrin at sharp

Mar 5, 2012, 11:56 AM

Post #4 of 15 (483 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

On 05 Mar 2012, at 8:14 PM, William A. Rowe Jr. wrote:

> 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.

This module solves a niche problem in complex website configurations, where a particular page might be made of tens of subprojects, with independent release cycles released by independent teams. The module combines multiple small css and javascript files into a single download, but without the penalty of losing support for conditional requests, and without amplifying a denial of service if a specific file is missing for whatever reason.

> I would join Jim in supporting mod_combine as a subproject, external
> to httpd trunk, for now.

I agree, +1.

>> [X] Option 2: adopt only as subproject

Regards,
Graham
--


wrowe at rowe-clan

Mar 6, 2012, 6:54 AM

Post #5 of 15 (471 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

On 3/5/2012 12:29 PM, Jeff Trawick wrote:
> On Sat, Mar 3, 2012 at 10:08 AM, William A. Rowe Jr.
> <wrowe [at] rowe-clan> wrote:
>> A proposal to adopt mod_combine is attached.
>>
>> [ ] Option 1: adopt as trunk module
>> [ ] Option 2: adopt only as subproject
> [X] Option 3: do not adopt

Before tallying, I just wanted to clarify your thoughts, Jeff.

If this module has a place in the public commons, I'm going to guess
that the BBC doesn't have an efficient open source development arm
who are prepared to deal with licensing and the ongoing concerns of
publishing source code for free.

So I tend to doubt that there is another vehicle other than the ASF
that would support Graham publishing this to the community. If you
don't believe it merits a subproject, then the two options remaining
would be a sandbox / unpublished module al la mod_arm4 (and I don't
think we want to propagate such examples), or a labs project for now.

So based on your concerns, how do you recommend Graham proceed with
this code?


trawick at gmail

Mar 6, 2012, 7:16 AM

Post #6 of 15 (471 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

On Tue, Mar 6, 2012 at 9:54 AM, William A. Rowe Jr. <wrowe [at] rowe-clan> wrote:
> On 3/5/2012 12:29 PM, Jeff Trawick wrote:
>> On Sat, Mar 3, 2012 at 10:08 AM, William A. Rowe Jr.
>> <wrowe [at] rowe-clan> wrote:
>>> A proposal to adopt mod_combine is attached.
>>>
>>>  [ ] Option 1: adopt as trunk module
>>>  [ ] Option 2: adopt only as subproject
>> [X] Option 3: do not adopt
>
> Before tallying, I just wanted to clarify your thoughts, Jeff.
>
> If this module has a place in the public commons, I'm going to guess
> that the BBC doesn't have an efficient open source development arm
> who are prepared to deal with licensing and the ongoing concerns of
> publishing source code for free.
>
> So I tend to doubt that there is another vehicle other than the ASF
> that would support Graham publishing this to the community.  If you
> don't believe it merits a subproject, then the two options remaining
> would be a sandbox / unpublished module al la mod_arm4 (and I don't
> think we want to propagate such examples), or a labs project for now.
>
> So based on your concerns, how do you recommend Graham proceed with
> this code?

Doesn't everyone have a half-dozen or [many] more modules which are
interesting for some purpose, might be useful for other developers to
look at for one reason or another, but do not merit a sub-project or
inclusion in the core server? I watch over a few I wrote that are in
the same boat -- offered to the project, rejected (or at least not
warmly welcomed), still used by a few other people who need to access
the current versions.

It can be awkward if a current (or, eventually, past) employer agrees
to ASL and agrees to make it some part of httpd (if accepted) but it
doesn't end up with a permanent home there, and thus isn't really the
ASF's but isn't Jeff's or Graham's either in the normal sense. Is
that what needs to be solved, or is this an issue of whether it gets
downloaded from apache.org?


wrowe at rowe-clan

Mar 27, 2012, 11:07 PM

Post #7 of 15 (432 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

From the Apache HTTP Server project;

On the combined topics of mod_firehose, mod_policy and mod_combine;

Declaring the vote on #3 failed (both originally, and the revote). RE-VOTE
#1 and #2 for firehose and policy modules (respectively) each have passed, for
adoption into httpd trunk. (Backport is a separate and additional matter.)
Firehose is already in httpd trunk, and policy awaits its import by minfrin.

Thank you for presenting these works to the project for consideration, Graham!

Now to resolve any last VP Legal concerns to get those first two modules
adopted without a theater of the absurd IP Intake Procedural hurdle. Fielding
had previously cleared that the entire ridiculous process was unnecessary and
the httpd project continues to choose not to observe it, pending any legitimate
illustration of its efficacy or benefit.

(Would you like your air conditioning unit fixed, there? Would ya? You might
have a clog in your IP Intake Hose. Central Services would be most displeased
if we muck around with it, ya know. Must keep this hush hush... hand me that
wrench...)

CC'ing VP Legal by way of legal-discuss, to ask one final time for hizzoner's
conclusion to https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 - The
httpd project considers the matter resolved, barring any legitimate objection
from our legal expertise (per prior communiques) before month's end.

Thanks all at httpd who voted on these three new modules, thanks Graham with
the cooperation of Simon and the BBC for their submission (oooh... the irony!!!),
and thank you in advance VP, Legal of the ASF for your considered recommendation
on the matter of procedural handling of the intake on this intellectual property.

Yours sincerely,

Bill [not Tuttle] Rowe
Former VP, Apache HTTP Server Project

[.Do hope you all enjoy the allegory, God love Terry Gilliam!]


minfrin at sharp

Mar 28, 2012, 6:21 AM

Post #8 of 15 (430 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

On 28 Mar 2012, at 1:02 PM, Sam Ruby wrote:

> Cut out the drama. It is not helpful here.
>
> The simple question is whether or not Graham has met the conditions specified in section 3 and 4 of the ICLA:
>
> http://www.apache.org/licenses/icla.txt
>
> Answer that in the affirmative, and you are done.

- I have a signed ICLA on file.
- I am a PMC member.
- The contribution was submitted to the ASF bugzilla by the BBC directly (ie not someone in their personal capacity), which forces account holders to agree to the following condition: "Certify that any object code, source code, patch, documentation, etc. that you may supply to an Apache project can be redistributed under the same license terms and conditions as the project itself."
- The contribution was made after a BBC-internal process was followed to sign off and clear the code for donation.

Can someone provide for me any concrete reason to suspect that the conditions in 3 and 4 might not have been met?

Regards,
Graham
--
Attachments: smime.p7s (4.26 KB)


wrowe at rowe-clan

Mar 28, 2012, 3:22 PM

Post #9 of 15 (428 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

Mobile mail..  sorry for brevity...

Doesn't the ICLA Graham has previously filed with the ASF already compel him to make no contribution unless those conditions are met?

After a decade is there any reason to believe he would act in contradiction to his sworn ICLA?

Sorry if you find this fatigueing or my humor irritating. Laughing at ourselves can be healthy medicine and inspiring to come to more sensible and less silly written policy. I'm quite finished being angry or irritated over such issues :)


-----Original message-----
From: Graham Leggett <minfrin [at] sharp>
To: Sam Ruby <rubys [at] intertwingly>
Cc: "William A. Rowe Jr." <wrowe [at] rowe-clan>, dev [at] httpd, legal-discuss [at] apache, Eric Covener <covener [at] gmail>, "Roy T. Fielding" <fielding [at] gbiv>, Simon Lucy <simon.lucy [at] bbc>
Sent: Wed, Mar 28, 2012 13:21:47 GMT+00:00
Subject: Re: [RE-VOTE #3] adoption of mod_combine subproject

On 28 Mar 2012, at 1:02 PM, Sam Ruby wrote:

> Cut out the drama. It is not helpful here.
>
> The simple question is whether or not Graham has met the conditions specified in section 3 and 4 of the ICLA:
>
> http://www.apache.org/licenses/icla.txt
>
> Answer that in the affirmative, and you are done.

- I have a signed ICLA on file.
- I am a PMC member.
- The contribution was submitted to the ASF bugzilla by the BBC directly (ie not someone in their personal capacity), which forces account holders to agree to the following condition: "Certify that any object code, source code, patch, documentation, etc. that you may supply to an Apache project can be redistributed under the same license terms and conditions as the project itself."
- The contribution was made after a BBC-internal process was followed to sign off and clear the code for donation.

Can someone provide for me any concrete reason to suspect that the conditions in 3 and 4 might not have been met?

Regards,
Graham
--


d.s at daniel

Mar 28, 2012, 4:04 PM

Post #10 of 15 (428 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

Guys. You were asked a boolean question. I'm pretty sure it was
intended to be taken literally. Have you considered just answering it?


wrowe at rowe-clan

Apr 3, 2012, 11:16 AM

Post #11 of 15 (423 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

On 3/28/2012 6:04 PM, Daniel Shahaf wrote:
> Guys. You were asked a boolean question. I'm pretty sure it was
> intended to be taken literally. Have you considered just answering it?

I believe that you meant to direct this to Graham and cc me, and not visa
versa, since I don't have such an answer. I also believe he did so (you
might also refer to the bugzilla ticket Sam hasn't replied to yet).
https://issues.apache.org/bugzilla/show_bug.cgi?id=52322

I had a question; Roy introduced a claim that he had, back in the day,
confirmed with legal that the process is not applicable for contributions
authored by committers, and some other contexts. The "IP Intake Process"
(as comfortable as a visit to the Gastroenterologist) needs to be reclaimed
by the *legal committee* which has that charge across all PMCs (incubator
included), and taken off the hands of the Incubator committee which isn't
given jurisdiction over TLPs. That Incubator documentation seems to be
inconsistent with the prerequisites as defined by Sam.

My question, where is the handling of large code submissions to existing
top level projects documented, to satisfy the concerns of legal@? Please
reclaim and refine. Are the TLPs accountable to Incubator guidance?
I don't see where that was assigned.

Thanks for giving some thought to the bigger picture, Daniel and team.


d.s at daniel

Apr 3, 2012, 12:01 PM

Post #12 of 15 (423 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

William A. Rowe Jr. wrote on Tue, Apr 03, 2012 at 13:16:22 -0500:
> On 3/28/2012 6:04 PM, Daniel Shahaf wrote:
> > Guys. You were asked a boolean question. I'm pretty sure it was
> > intended to be taken literally. Have you considered just answering it?
>
> I believe that you meant to direct this to Graham and cc me, and not visa
> versa, since I don't have such an answer.

Don't pay too much attention to the To/Cc. Sometimes I just press
"Reply all" and go with the default partitioning.

> I also believe he did so (you
> might also refer to the bugzilla ticket Sam hasn't replied to yet).
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52322

Thanks for the pointer -- I only read the legal-discuss@ thread, not the ticket.


wrowe at rowe-clan

Apr 3, 2012, 5:14 PM

Post #13 of 15 (418 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

On 4/3/2012 2:01 PM, Daniel Shahaf wrote:
> William A. Rowe Jr. wrote on Tue, Apr 03, 2012 at 13:16:22 -0500:
>
>> I also believe he did so (you
>> might also refer to the bugzilla ticket Sam hasn't replied to yet).
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=52322
>
> Thanks for the pointer -- I only read the legal-discuss@ thread, not the ticket.

As Sam pointed out, individual ticket assignments to the VP Infra will
not be scalable. Sam's prime weakness is an aversion to delegation.
So we fall again down the rabbit hole.

I brought the matter to legal-internal with a statement "Roy asserts..." and
a request "Just fix it in respect to policy, or we will presume Roy is correct".

I'm afraid this may have been misinterpreted as a request to cast judgement
on a specific case, when there was no such request. No specific case review
was requested. Policy review was requested.

Sam's response now appears to be, [liberally paraphrasing] "If it adheres
to the terms and conditions and is offered in good faith under those terms
of the Individual Contributor License Agreement and the Apache License 2.0,
by a committer, their employer and any other assigns to that copyright and
relevant patents, and the committer asserts this is true, then the PMC must
be the one to make that judgement call".

Which is what Roy argued this entire time and seems awfully sensible to me.

So sorry to waste the legal team's time, and please be considerate and don't
waste ours either. If it is time to update process docs, do it already.


wrowe at rowe-clan

Apr 3, 2012, 6:37 PM

Post #14 of 15 (417 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

On 4/3/2012 7:28 PM, Sam Ruby wrote:
> On 04/03/2012 08:14 PM, William A. Rowe Jr. wrote:
>>
>> Sam's prime weakness is an aversion to delegation.
>
> You have that exactly 180 degrees backwards. I am not responding precisely BECAUSE I
> believe in delegation.

As well you should... it is for the PMC to decide...

> As danielsh pointed out, I asked a simple binary question. Instead of a simple binary
> reply, I get answers in the form of a question.

Why did you ask a question? Nobody asked you to ask a question, but rather...

People including myself, Eric, Graham and Roy are asking you a question.
Where is the process documented? The PMC will collectively exercise the
process and protect the integrity of the foundation, as you yourself have
insisted that we do. We don't need you, on behalf of ASF legal, to determine
what the heck Graham is doing, but we need to you to document how Eric, PMC VP
is to supervise the project which is delegated to his direct oversight, and
how we can support him in that supervision.

> Don't do that.

Et tu

> I have stated that this is up to the PMC to decide. I have pointed to the criteria. If
> the PMC is note only welcome to execute according to that criteria, it absolutely is
> expected to do so.

Excellent. I think we agree on critera. Our only difference of opinion is that,
on my reading of the ICLA, it's impossible for a committer to do what you are
asking the committer to confirm they have not done.

> Should the PMC operate outside of that criteria, the Legal Affairs committee will act.
> Answer that question with an affirmative, and there will be no reason for the Legal
> Affairs committee to intercede.

I'm certain it will and welcome the committee's proactive activity to resolve
this for the benefit of all TLPs.

> Meanwhile, do NOT continue to attempt pass off your responsibility to others.

I will absolutely not shirk my own responsibility, which in this matter, is
neither the responsibility of a committer placing code at the ASF, an officer
acting under the direction of the BoD, nor a a director of the ASF. Which is
to say, my entire responsibility as a member of the project and the foundation
consisted of bringing the concern to the chair of the project and VP Legal,
and let you all have your fun. I'm done with this dialog. Cheers.


jim at jaguNET

Apr 4, 2012, 5:52 AM

Post #15 of 15 (417 views)
Permalink
Re: [RE-VOTE #3] adoption of mod_combine subproject [In reply to]

On Apr 3, 2012, at 9:37 PM, William A. Rowe Jr. wrote:
>
> I will absolutely not shirk my own responsibility, which in this matter, is
> neither the responsibility of a committer placing code at the ASF, an officer
> acting under the direction of the BoD, nor a a director of the ASF. Which is
> to say, my entire responsibility as a member of the project and the foundation
> consisted of bringing the concern to the chair of the project and VP Legal,
> and let you all have your fun. I'm done with this dialog. Cheers.
>

I will be honest: I have no idea what this whole debate is about.
From the vote within the PMC, it's clear that the consensus is
to fold the code in, that we are satisfied that we are covered,
IP-wise, due to Graham's iCLA on file as well as other guarantees
noted in the (long) thread regarding the code submission.
So what is the problem?? That someone doesn't like the result
of the vote and is hoping to have it overturned, somehow??

I also fail to see how this codebase is any different from other
modules which we've folded in from "outside" like mod_proxy_html
and Paul's various heartbeat/cluster stuff which came in with hardly
any debate and certainly not dragging legal into it all...

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.