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.
Comments?
Bill
