Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <43F2D156.7000403@rowe-clan.net>
Date: Wed, 15 Feb 2006 00:59:34 -0600
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
MIME-Version: 1.0
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
CC: Ian Holsman <lists@holsman.net>, dev@apr.apache.org
Subject: Re: status of memcached code in the trunk
References: <43F162DB.4060403@holsman.net> <43F165A0.5040004@rowe-clan.net>
In-Reply-To: <43F165A0.5040004@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

To close this discussion for the present moment...

William A. Rowe, Jr. wrote:
> Ian Holsman wrote:
> 
>> Hi.
>>
>> when the memcache code was initially comitted, the code was vetod (or 
>> was it -1' voted i can't remember) because it only worked against one 
>> product memcached (http://www.danga.com/memcached/).
>>
>> this actually isn't the case anymore. the folks over @ mediawiki wrote 
>> their own memcached server called TugelaCache. 
>> (http://meta.wikimedia.org/wiki/Tugelacache)
> 
> 
> This is definately progress to see multiple implementations.
> 
> I'm still concerned that it's a non-functional API unless a backend is 
> built and configured; therefore...

I'm reverting my veto over adoption of this code in apr-util 1.3.0.  However...

>> So I'd like to formally open the old-wound and start this conversation 
>> over again.
>>
>> based on discussions on IRC today, It seems that the veto/vote has 
>> changed as the memcache code is not testable in a self-contained way, 
>> instead of it being a 1-horse standard.
> 
> since it's obviously an extensible standard, we kicked around something
> like the following idea which makes apr_memcache available out-of-the-box,
> as it were, and immediately testible.  An implementation which;
> 
>   * is created by apr_memcache_start_thread() or apr_memcache_start_proc()
>     which spins up a thread or forks off an instance of this mini-memcache
> 
>   * is not distributed (it's the single loopback)
> 
>   * is usable by multiple threads, or multiple processes, al la worker
>     and prefork model httpd
> 
>   * is sizeable to something more modest than 2GB, for example, 64kb or
>     256kb just for testing purposes (an arg to apr_memcache_start_())
> 
>   * is implemented purely with apr itself.
> 
> Any thoughts on solving the 'glue to the outside world' complaint with this
> rather simplistic implementation?  We wouldn't be seeking to 'usurp' the
> authors of these now two (and hopefully someday, more) providers.  We would
> simply be inserting the bare-bones into apr-util, and letting our users 
> build upon this as much as they like with the now-several backends available.

everyone is focused on the 'can we test this' question.

I would continue to veto any single line containing apr_memcache[...] in httpd
so long as there isn't a trivial backend as part of apr-util that users can
deploy without obtaining, and installing, a memcached process.

Of course someone could simply hack in something like
if (apr_memcache_init()) {...} else {apr_mmap_create()... }
or something similar, but it reflects badly on apr-util itself and would prove
to be error prone in the long run.  By offering the simple implementation, it
would be possible to write the code once in httpd and be done with it, while we
delegate the alternative provider to apr-util.

Plugging into 'more things' is great, but this is something so trivial for the
common use case in httpd that I still believe apr-util should provide the simple
implementation, itself, and leave it to others to develop rich implementations.

Bill