apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: Reading over, reading under, missing the plain point
Date Thu, 16 Feb 2006 00:40:25 GMT
On 2/15/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> apr-dev folk,
>    the major reason for most flame wars etc is the inability to read email
> statements for what they are;  reading sarcasm where none is intended
> or reading verbatim where humor/sarcasm is intended.  And most importantly,
> on a technical list, reading something into a post some context that isn't
> there based on the reader's perspective.
>    My last post reverting the veto of memcache (and asserting a hypothetical
> veto by second-guessing where this discussion moves next) started with a
> statement that testing is only *one* aspect.  The crux of the objection is
> that what memcache does is dirt simple stupid, and forcing users to seek out
> a package to do that dirt simple stupid function/feature indicates laziness
> and sloth on the part of the implementors (us).  My message went on to express
> how the alternate rich implementations of memcached allow users to scale these
> functions in all sorts of good directions, but that at the most basic app,
> there's no reason for us not to 'just do it' ourselves.
>    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.

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.

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.

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.


View raw message