Thanks for the detailed response and sorry for the slow reply ;) On Thu, Mar 06, 2008 at 02:33:12PM -0800, Chris Darroch wrote: > I was a little puzzled by the name "socache" because I assumed > "so" meant "shared object", like mod_so, until I read the code comments. > I wondered if it was true that people would only use this kind of > interface to store small objects -- I won't, for one. (We can > migrate our session cache to this interface and we cram all kinds of > data in there.)
I think it's appropriate that the "smallness" is brought out: 1) the fact that some providers (shmcb, memcache at least) have fixed size limits means any consumer must be designed to cope with that, 2) for a cache which could store arbitrarily large objects, you'd want a different, streamy, interface, which didn't just pass data blobs as (char *, size) pairs. > Also, I wondered if the term "cache" was necessarily accurate, if > some providers allow unlimited persistent storage (DBM, DBD, etc.) > I'm hoping to be able to store things with expiry=0 to mean "persist as > long as possible". "Cache" also overlaps with the mod_cache and > friends which implement something rather different. Again I do think this is appropriate; any consumer of this API which requires unlimited persistent storage should just code directly against a database API to get that; you can't get that guarantee with shmcb/memcache. > Should the expiry argument to store() be an apr_interval_time_t > or an apr_time_t? I'd love to be allowed 0 to mean "don't expire" too. > And perhaps apr_size_t for the key and value lengths? Great questions. I would prefer to use apr_size_t but all the existing providers expect unsigned int, so it would mean ugly casting in N place; I'm not sure what's the best thing to do here. I'm also not sure about using millisecond-precision expiry; since all the current providers using second-precision, it seems unnecessary to pretend otherwise. Do you envisage a need for millisecond-precision expiry? > Is there a particular reason for the store(), retrieve(), delete() > names? APR hashes use get/set (set NULL to delete), tables use > get/set/unset, and inclined toward following the DBM names and > changing retrieve() to fetch(). Thoughts? No strong opinions here ;) joe
