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: Reading over, reading under, missing the plain point
Date Thu, 16 Feb 2006 04:54:19 GMT
Garrett Rooney wrote:
> On 2/15/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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

Mime
View raw message