You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2008/12/12 11:07:48 UTC
Re: svn commit: r724745 - in /httpd/httpd/trunk:
include/ap_socache.h modules/ssl/ssl_scache.c
On Tue, Dec 09, 2008 at 10:30:51AM -0800, Chris Darroch wrote:
> Joe Orton wrote:
>
>> * include/ap_socache.h: Use C++ safety wrappers, and rename ->delete
>> to ->remove since the former is a C++ reserved word.
>
> Thanks again for the socache refactoring! I've been trying to
> keep these two modules up-to-date with both the socache stuff and
> Apache ZooKeeper (http://hadoop.apache.org/zookeeper/) releases:
>
> http://people.apache.org/~chrisd/projects/shared_map/
Both modules look very neat! Are you going to commit them? I might
debate the naming of mod_shmap ;)
> A couple of things came up while I was writing these modules
> which I think it would be great to tackle before the socache API is
> locked for 2.4:
>
> - 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!
> And -- I know, I know, I'm a glutton for punishment when it comes
> to naming issues -- I still feel that "socache" as a name for this
> API does it an injustice, since it can be used for a lot more than
> just a small-object cache. The ZK module, at a minimum, I think shows
> how you could use it for something that's not a cache at all, and
> not necessarily for small objects either.
>
> Something more generic to the idea of a common, shared key/value
> storage API seems like a good idea to me. But if no one sees this as
> a concern, I'll shut up forever about it. I promise. :-)
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.
If you were to design an API for caching objects of arbitrary size,
you'd do it differently (it would need to be streamy, not simply passing
char */size pairs around).
If you were to design an API for persistent storage of objects, you'd do
it differently - you'd take out the "expiry", and you'd probably want to
add hooks for manipulation/discovery of the namespace.
So an API for persistent storage of objects of arbitrary size might like
something a lot like the mod_dav repos provider interface -
dav_hooks_repository.
Regards, Joe
Re: svn commit: r724745 - in /httpd/httpd/trunk: include/ap_socache.h
modules/ssl/ssl_scache.c
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Joe Orton wrote:
> mod_shmap would be useful at least in modules/test so I can write some
> perl-framework tests for mod_socache!
OK, I'll think about doing that. The m4/dsp/NWGNU wizardry required
makes me tired just thinking about it, though. :-) In the meantime,
I think they compile again against the latest API.
> Ah, I was waiting for Ruediger to ask ;)
Ho ho ho -- yes, he and Jim have caught me out on too many things
to count.
> 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 ;)
Personally, I'd have to agree with you in principle about maybe
not needing to track unreleased code so carefully. Interesting
thought about provider versions. I wonder if there are other providers
elsewhere in trunk which we should really bump.
> 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>
Well, there is that. If no one seems to think mod_so and
mod_socache* conflict name-wise, I'll just hush up permanently on
this point. Cheers,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: svn commit: r724745 - in /httpd/httpd/trunk: include/ap_socache.h
modules/ssl/ssl_scache.c
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/12/2008 09:33 PM, Joe Orton wrote:
> On Fri, Dec 12, 2008 at 11:15:49AM -0800, Chris Darroch wrote:
>> Joe Orton wrote:
>>
>> 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
I must have missed this during my review. Shame on me :-).
Regards
Rüdiger
Re: svn commit: r724745 - in /httpd/httpd/trunk:
include/ap_socache.h modules/ssl/ssl_scache.c
Posted by Joe Orton <jo...@redhat.com>.
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
Re: svn commit: r724745 - in /httpd/httpd/trunk: include/ap_socache.h
modules/ssl/ssl_scache.c
Posted by Chris Darroch <ch...@pearsoncmg.com>.
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