Ian Holsman wrote:
I've been making more and more use of this library, and I think it would
benefit APR and it's userbase significantly if it was included in the
core codebase in apr-util.
I'm concerned that this commit primarily benefits that project's userbase,
which is a sufficient reason to veto the project as against APR's charter.
apr_memcache is library which lets your process talk to a set of
distributed memcached servers (see www.danga.com/memcached/) and allows
you to have one shared cache across a group of machines with a simple to
use interface.
Yes, it's very elegant (at least, the accessor design is). Kudos on
a very slick solution.
However, this cannot be considered any sort of abstraction, or declared
some 'reference implementation'. apr_memcache specificially solves this
one issue, connecting to memcached, and it looks like this would not (and
probably should not) become something else.
I have used this code personally for:
- a module to provide bandwidth protection over a server farm
- to cache intermediate results off a busy server. (instead of using
shared mem)
and I'm sure there are others who have used it successfully as well.
The list of users alone is obvious praise for how effective this daemon is.
However, there's no way to reconcile adding this wrapper with;
The mission of the Apache Portable Runtime (APR) project is to create
and maintain software libraries that provide a predictable and consistent
interface to underlying platform-specific implementations. The primary goal
is to provide an API to which software developers may code and be assured of
predictable if not identical behaviour regardless of the platform on which
their software is built, relieving them of the need to code special-case
conditions to work around or take advantage of platform-specific
deficiencies or features.
considering that
* there is no 'platform' portability problem here
* there is no 'implementation' portability problem here
and most significantly, this implementation/wrapper introduces an API and
method too focused on a single implementation, to the detriment of actually
providing an alternative solution.
For these reasons, from apr-util, please revert.
I'm sure folks won't be happy with this position, so I'll spin a new thread
to discuss productive solutions.
Bill
