Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4EDAA288.4020009@rowe-clan.net>
Date: Sat, 03 Dec 2011 16:28:24 -0600
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Are we there yet?
References: <201112030048.19359.sf@sfritsch.de> <4ED9D076.4060604@gknw.net>
In-Reply-To: <4ED9D076.4060604@gknw.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12/3/2011 1:32 AM, Gregg L. Smith wrote:
> On 12/2/2011 3:48 PM, Stefan Fritsch wrote:
>> - the follwing modules added since 2.2 lack documentation
>
>> - mod_socache_dbm
>> - mod_socache_memcache
>> - mod_socache_shmcb
>
> These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be
> sufficient IMHO.

It isn't.  Someone trimming their LoadModule lines will undoubtedly
hit the wall trying to figure out why they couldn't just switch from
memcache or dbm back to shmcb.  Someone else will break there server
simply removing unfamiliar modules from the list, particularly one
which appears nowhere in the ASF HTTP Server module documents lists.

This, and the mod_slotmem_* objects, really make lousy modules.

I can understand wanting to extend socache and slotmem into much
more complex or experimental backend stores.  Extensibility is good.
But for the time being, and for this fundamental set...

can we please trash all 6 "modules" and add the code into core?
It seems to me that even apreq extensions are in a more usable,
documented state than these... and we refuse to incorporate it.
I think we got things backwards.

Bill