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 jorton@redhat.com designates
 66.187.237.31 as permitted sender)
Date: Fri, 12 Dec 2008 20:33:31 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@httpd.apache.org
Subject: Re: svn commit: r724745 - in /httpd/httpd/trunk:
	include/ap_socache.h modules/ssl/ssl_scache.c
Message-ID: <20081212203331.GA25255@redhat.com>
Mail-Followup-To: dev@httpd.apache.org
References: <20081209151908.BDA102388879@eris.apache.org>
 <493EB95B.3040105@pearsoncmg.com> <20081212100748.GA6413@redhat.com>
 <4942B865.4060801@pearsoncmg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4942B865.4060801@pearsoncmg.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

On Fri, Dec 12, 2008 at 11:15:49AM -0800, Chris Darroch wrote:
> 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?

mod_shmap would be useful at least in modules/test so I can write some 
perl-framework tests for mod_socache!

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

Ah, I was waiting for Ruediger to ask ;) Personally I think it is 
redundant maintaining fine-grained API versions across changes in 
unreleased code.  Also, if we are going to API version, arguably it 
should be done by bumping the provider version.  But really, I don't 
care ;)

[on naming...]
>   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?

Personally, I don't think it's a big enough deal to repaint the 
bikeshed.  It's an API for module developers, so, if someone gets 
confused with mod_so, what's the worst that could happen? <cue disaster 
movie>

joe