Garrett Rooney wrote:
On 2/15/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Throughout this thread, testing was one attribute. It's the only attribute
which people have addressed in their replies. I'd like to see someone talk
to the actual aspect of 'why the heck dispatch every caching application
to external prerequisites?' and get over the testing aspect, which some people
will clearly be interested in, and some clearly detest (all pun intended :-)
I think the core issue here is that there's a difference of opinion as
to where the line should be drawn with regard to what kind of code can
be a part of the APR project.
Well said. This is an ongoing, evolutionary process, the line has moved back
and forth often over the evolution of apr-util especially.
You seem to be of the opinion that if it isn't providing portability
of some sort then it shouldn't be there at all. Others (myself
included) feel that the line is more flexible, and that if it doesn't
prove to be a burden (i.e. by requiring third party libraries or
making the build take too long or making the distributed tarball
overly large) there's no reason we can't also include things simply
because they're useful to have.
And in part apr v.s. apr-util draws part of this line. On the one hand,
apr can have a very narrow scope, and apr-util can have a broader scope
with external dependencies. Heck, I'm about to inject an optional
dependency into apr, but the key factor is that the API to apr or
it's supported functionality will never change. [This is all moving
forwards 1.3 sort of work, nothing involving a ton of backports, to
be discussed as my submissions are ready.]
I personally feel that the memcache code is in this category, it's a
single .c file, doesn't link to an external library, and provides
something that people (myself included) have found to be quite useful.
Thus, I don't see a reason not to have it.
Someone pointed out the db's, and why don't I have the same attitude? The
reason is that apr_sdbm provides a simple, baseline implementation. Better
options exist for those that want to build them in, but that functionality
is always there.
The newer sql and older ldap features I've supported because they do help
ease deployment between different toolsets; even though we would never
implement a 'minimal sql' or 'minimal ldap' ourselves, the behavior adds
flexibility, not any 1:1 mapping. Same for the db support, and in theory
even the apr_xlate support (there is no reason it -couldn't- link into the
IBM's ICU library, we just haven't written such bindings. But it's designed
in such a way as to be possible.)
Yes, it would also be interesting to have a generic cache framework
that lets you use either memcache, an in-memory cache, a dbm file, or
whatever other backend you're inclined to use, but I don't think the
desire for such a thing should keep us from also having an interface
to easily talk to a memcache server, considering that the cost of
having such a thing in the system is vanishingly small.
And the cost of a 'minimal implementation' is equally small, yet ensures
that someone picking up apr-util has something useful without the third
party libs.
I've dropped that objection for including it into apr-util; in fact I think
it will help those projects who implement the memcached interface to grow
in popularity. Let's face it, adding code to apr-util around another lib
*is* endorsing that lib (or daemon). And the fact that there is already
more than one implementation adds credibility to the API.
My hint is that this won't be acceptable in httpd until my concern is then
addressed and apr-util has this minimal implementation (using the memcached
interface already defined, that's just fine.) Why won't I tollerate it?
I'm going back in time to the three cache providers in mod_ssl. There will
always be a FOTM which gets more attention, more interest, more stability.
The three cache provider options were a disaster. mod_mem_cache is already
showing these same symptoms when compared to mod_disk_cache.
So the day I see two code paths fork in httpd, once that requires memcached
and one that uses another local-machine technology, that's when I will be
slamming on the breaks. Why? Because we know full well the first will be
well considered and tested, and the second will languish.
Only if there can be a single implementation, which doesn't have an external
heavy dependency (memcached) for a simple application (one server, a few hosts,
low/modest traffic), using the same API, that's when I would green light such
an addition into httpd.
None of this is relevant to the list, but I thought it worth pointing out that
httpd is probably not the only apr-util consumer who will wrestle with the
issues of which apr-util interfaces to use, and which to ignore.
Bill
