Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of jorton@redhat.com designates
 66.187.237.31 as permitted sender)
Date: Fri, 12 Dec 2008 10:07:48 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@httpd.apache.org
Subject: Re: svn commit: r724745 - in /httpd/httpd/trunk:
	include/ap_socache.h modules/ssl/ssl_scache.c
Message-ID: <20081212100748.GA6413@redhat.com>
Mail-Followup-To: dev@httpd.apache.org
References: <20081209151908.BDA102388879@eris.apache.org>
 <493EB95B.3040105@pearsoncmg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <493EB95B.3040105@pearsoncmg.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

On Tue, Dec 09, 2008 at 10:30:51AM -0800, Chris Darroch wrote:
> Joe Orton wrote:
>
>> * include/ap_socache.h: Use C++ safety wrappers, and rename ->delete
>>   to ->remove since the former is a C++ reserved word.
>
>   Thanks again for the socache refactoring!  I've been trying to
> keep these two modules up-to-date with both the socache stuff and
> Apache ZooKeeper (http://hadoop.apache.org/zookeeper/) releases:
>
> http://people.apache.org/~chrisd/projects/shared_map/

Both modules look very neat!  Are you going to commit them?  I might 
debate the naming of mod_shmap ;)

>   A couple of things came up while I was writing these modules
> which I think it would be great to tackle before the socache API is
> locked for 2.4:
>
> - have all providers consistently return APR_NOTFOUND from retrieve()
>  when an item is not found
>
> - pass a pool argument for temporary allocations to store() and remove()
>
> - return an apr_status_t instead of void from remove() and maybe
>  also destroy()

Those all seem like good ideas - thanks!

>   And -- I know, I know, I'm a glutton for punishment when it comes
> to naming issues -- I still feel that "socache" as a name for this
> API does it an injustice, since it can be used for a lot more than
> just a small-object cache.  The ZK module, at a minimum, I think shows
> how you could use it for something that's not a cache at all, and
> not necessarily for small objects either.
>
>   Something more generic to the idea of a common, shared key/value
> storage API seems like a good idea to me.  But if no one sees this as
> a concern, I'll shut up forever about it.  I promise.  :-)

Well, I stand by my argument on this before: the interface is designed 
explicitly for abstraction of small object caching, emphasis both on the 
small and the caching.  Sure, you can implement more general backends, 
but that doesn't change the design of the API.

If you were to design an API for caching objects of arbitrary size, 
you'd do it differently (it would need to be streamy, not simply passing 
char */size pairs around).

If you were to design an API for persistent storage of objects, you'd do 
it differently - you'd take out the "expiry", and you'd probably want to 
add hooks for manipulation/discovery of the namespace.

So an API for persistent storage of objects of arbitrary size might like 
something a lot like the mod_dav repos provider interface - 
dav_hooks_repository.

Regards, Joe