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: [vote] include apr_memcache into the apr-util trunk
Date Mon, 31 Oct 2005 17:37:10 GMT
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

Mime
View raw message