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: status of memcached code in the trunk
Date Tue, 14 Feb 2006 05:07:44 GMT
Ian Holsman wrote:
> Hi.
> when the memcache code was initially comitted, the code was vetod (or 
> was it -1' voted i can't remember) because it only worked against one 
> product memcached (http://www.danga.com/memcached/).
> this actually isn't the case anymore. the folks over @ mediawiki wrote 
> their own memcached server called TugelaCache. 
> (http://meta.wikimedia.org/wiki/Tugelacache)

This is definately progress to see multiple implementations.

I'm still concerned that it's a non-functional API unless a backend is built
and configured; therefore...

> So I'd like to formally open the old-wound and start this conversation 
> over again.
> based on discussions on IRC today, It seems that the veto/vote has 
> changed as the memcache code is not testable in a self-contained way, 
> instead of it being a 1-horse standard.

since it's obviously an extensible standard, we kicked around something
like the following idea which makes apr_memcache available out-of-the-box,
as it were, and immediately testible.  An implementation which;

   * is created by apr_memcache_start_thread() or apr_memcache_start_proc()
     which spins up a thread or forks off an instance of this mini-memcache

   * is not distributed (it's the single loopback)

   * is usable by multiple threads, or multiple processes, al la worker
     and prefork model httpd

   * is sizeable to something more modest than 2GB, for example, 64kb or
     256kb just for testing purposes (an arg to apr_memcache_start_())

   * is implemented purely with apr itself.

Any thoughts on solving the 'glue to the outside world' complaint with this
rather simplistic implementation?  We wouldn't be seeking to 'usurp' the
authors of these now two (and hopefully someday, more) providers.  We would
simply be inserting the bare-bones into apr-util, and letting our users build
upon this as much as they like with the now-several backends available.



View raw message