Re: [PATCH] ap_socache.h & mod_socache_*

[Joe Orton <jo...@redhat.com>]

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

Re: [PATCH] ap_socache.h & mod_socache_*

[Graham Leggett <mi...@sharp.fm>]

Joe Orton wrote:

> 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.

One thing I see a definite use for a small object cache is in 
mod_disk_cache, to store the headers of requests. This will allow the 
update of headers without the song and dance that we have to go through 
now to do this.

Headers fit the criterion of "small" and "fixed size limits", but would 
need to be persisted across a server restart somehow, ie with DBM or DBD.

Regards,
Graham
--