Its not squid, but I've also been goofing around with a memcached
based mod_cache provider that would do just this. Your http based
caching would all be stored/fetched via memcached calls (using
apr_memcache). Its one of like 2 or 3 of my little pet projects, so it
only gets worked on when I have a chance, but I thinks its close to
being usable at this point. I haven't tested it fully or really
benchmarked it, though.
On 7/8/07, Les Mikesell <[EMAIL PROTECTED]> wrote:
josh rotenberg wrote:
> We were looking at having some kind of simple, distributed key/value
> storage system for storing chunks of stuff (html, xml, whatever) with
> simple, namespaced keys. Stuff that doesn't belong in Mysql, and fits
> more along the lines of Berkeley DB, but is accessible over the
> network and can be accessed with a protocol instead of an API. We
> already use memcached, and we use at least 4 different languages, so
> coming up with a new client library for each of those didn't sound so
> fun, so the memcached protocol fit almost perfectly.
Maybe someone could glue a memcached client into squid as a replacement
for its in-memory cache so it can span over multiple servers. That way
you inherit all the cache-control parsing, access control, and a fast
and tunable disk backing store. The catch would be that you probably
also want direct client access to the same data without having to go
through the squid proxy. Could that be done with some kind of key naming
convention mapped into the http requests?
--
Les Mikesell
[EMAIL PROTECTED]
