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
|