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
