httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r724745 - in /httpd/httpd/trunk: include/ap_socache.h modules/ssl/ssl_scache.c
Date Fri, 12 Dec 2008 20:33:31 GMT
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

Mime
View raw message