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: <4942B865.4060801@pearsoncmg.com>
Date: Fri, 12 Dec 2008 11:15:49 -0800
From: Chris Darroch <chrisd@pearsoncmg.com>
Organization: Pearson CMG/CTG
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.18) Gecko/20081114 SeaMonkey/1.1.13
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r724745 - in /httpd/httpd/trunk:	include/ap_socache.h
 modules/ssl/ssl_scache.c
References: <20081209151908.BDA102388879@eris.apache.org>
 <493EB95B.3040105@pearsoncmg.com> <20081212100748.GA6413@redhat.com>
In-Reply-To: <20081212100748.GA6413@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Joe Orton wrote:

> Both modules look very neat!  Are you going to commit them?  I might 
> debate the naming of mod_shmap ;)

   Heh, thanks.  I don't know, I hadn't really thought about committing
them ... maybe the shmap one is more useful to other folks?


>> - have all providers consistently return APR_NOTFOUND from retrieve()
>>  when an item is not found
>>
>> - pass a pool argument for temporary allocations to store() and remove()
>>
>> - return an apr_status_t instead of void from remove() and maybe
>>  also destroy()
> 
> Those all seem like good ideas - thanks!

   I saw the commit, thank you!  I confess I'm not sure what I was
thinking when I said we should pass a pool to remove(), since it already
took one.  Maybe destroy() should take a pool too?  Perhaps that's
overkill.

   One other thought ... does this change need an ap_mmn.h bump?


> Well, I stand by my argument on this before: the interface is designed 
> explicitly for abstraction of small object caching, emphasis both on the 
> small and the caching.  Sure, you can implement more general backends, 
> but that doesn't change the design of the API.

   OK, I'll buy that and be quiet ... except for one thing.  :-)

   I feel like "so" is already quite overloaded with the meaning
"shared object", and especially so in this case, since we have the
long-standing mod_so already in place.  To my mind, mod_socache*
could easily imply to others that these modules are somehow related
to caching .so files in memory, or something like that.

   Is there anything we could come up with that doesn't imply any
connection with mod_so and .so files?  I hunted around for something
in the past and came up with shmap, but I could live with dcache or
scache or something else that seemed unique within in the httpd module
population.  Any thoughts?

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B