William A. Rowe, Jr. wrote:
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 ;-)
first, can you stop with the 'oddball' comments. If you don't think
memcached is useful, fine. but for others it serves a need which isn't
there in the current apr/util family, and that is a distributed/shared
cache.
memcached has been around for years, has a large user base, and plays a
part in several large corporations, while you might not find this
useful, others do.
as for the parameter issue, from what I remember the general APR ethos
is garbage in garbage out.
We don't do parameter checking, in most of the apis we have, from what I
recall. and making it a different field size will cause surprise for
users when they try to cache 2^32+1 bytes and it fails. better to tell
the user this is exactly how much you can do straight off and let the
compiler issue the warning instead of doing it at runtime.
It also sets the perception that this is for caching *smallish* things,
not 700M ISOs.
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.
apr_memcache is a interface to a single-process memory cache.
It also has the advanced feature of segregating by the key value to a
set of single process memory caches (cachee?), which can be distributed
across a set of machines. (and provide a common cache across a entire
server farm)
so the 'mem' stands for memory as it doesn't use disk (similar to
mod_mem_cache and mod_disk_cache)
and the 'cache' stands for non-persistent, as there is no guarantee that
the data you put in there 5 seconds ago will still be there the next
time you ask.
we could call it apr_dist_mem_cache if you prefer ?
Bill
