apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r329089 - in /apr/apr-util/trunk: build.conf include/apr_memcache.h memcache/ memcache/apr_memcache.c
Date Fri, 28 Oct 2005 21:34:28 GMT
Paul Querna wrote:
> Joe Orton wrote:
> 
>>- apr_memcache_hash's data_len argument, apr_memcache_conn_t.blen , 
>>storage_cmd_write's *_size  arguments are all apr_uint32_t and look like 
>>they should be apr_size_t, any reason why that is?
> 
> Ah, now I remember why.  The memcached protocol states that these data
> lengths are all unsigned 32bit ints.  So, they can never hold values
> larger, or the server will not understand.

So, we violate a basic apr design principal for an oddball service that we
are seeking to support?  Or return APR_EINVAL when someone tries to set
aside 10GB?  (This is a rather funny quibble when you consider how horrid
using an external socket-cached data store to set aside 10GB for 'quick
access' later on ;-)

If apr-util is designed to be a pluggable abstraction layer, and we all
concur that

   char *buf;
   apr_size_t *bufsize;
   apr_dosomething(*buf, &bufsize);

is our normalized style, obviously this patch was correct, irrespective
of whatever this particular backend cache supports.

FYI - why apr_memcache?  Unless it's either an in-memory cache, or some
cache virtualized by page-fault retrieval, this is definately misnamed,
or beholden to one oddball external project.

Bill

Mime
View raw message