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
