Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [RE-VOTE #3] adoption of mod_combine subproject
From: Graham Leggett <minfrin@sharp.fm>
In-Reply-To: <4F550287.8050209@rowe-clan.net>
Date: Mon, 5 Mar 2012 21:56:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F238308F-0E9A-4F29-8279-4787CB4F7510@sharp.fm>
References: <83B99491-B66E-40B6-8008-8D4302B332E3@sharp.fm>
 <4F5233D2.7040004@rowe-clan.net> <4F550287.8050209@rowe-clan.net>
To: dev@httpd.apache.org

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