httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: [PATCH] ap_socache.h & mod_socache_*
Date Tue, 08 Apr 2008 10:53:25 GMT
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 

>   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 

>  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 ;)


View raw message