To close this discussion for the present moment...
William A. Rowe, Jr. wrote:
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...
I'm reverting my veto over adoption of this code in apr-util 1.3.0. However...
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.
everyone is focused on the 'can we test this' question.
I would continue to veto any single line containing apr_memcache[...] in httpd
so long as there isn't a trivial backend as part of apr-util that users can
deploy without obtaining, and installing, a memcached process.
Of course someone could simply hack in something like
if (apr_memcache_init()) {...} else {apr_mmap_create()... }
or something similar, but it reflects badly on apr-util itself and would prove
to be error prone in the long run. By offering the simple implementation, it
would be possible to write the code once in httpd and be done with it, while we
delegate the alternative provider to apr-util.
Plugging into 'more things' is great, but this is something so trivial for the
common use case in httpd that I still believe apr-util should provide the simple
implementation, itself, and leave it to others to develop rich implementations.
Bill
