On 20 Jun 2007, at 11:05 am, Dan Muresan wrote:
That's why my generic cache interface is intended to be a front-end
to different cache implementations, with a common interface, and some
tools built on top of that interface (such as memoizing functions).
Yes, I understand the philosophy, but b
That's why my generic cache interface is intended to be a front-end
to different cache implementations, with a common interface, and some
tools built on top of that interface (such as memoizing functions).
Yes, I understand the philosophy, but before you can make a generic API,
one should study
On 20 Jun 2007, at 10:19 am, Dan Muresan wrote:
Ok, so that's one vote for separate 'memcached' and 'cache' eggs.
I would vote against a generically-named cache egg... There are
many types of caches (depending on storage medium, indexing, time
complexities of caching/retrieval, expiration str
Ok, so that's one vote for separate 'memcached' and 'cache' eggs.
I would vote against a generically-named cache egg... There are many
types of caches (depending on storage medium, indexing, time
complexities of caching/retrieval, expiration strategies etc)
Best,
Dan
_
On 20 Jun 2007, at 3:12 am, Graham Fawcett wrote:
Since Chicken continuations are serializable, you could also store
them as values in the cache. Not sure of a use-case, but there you
are.
Interesting... Well, continuation-based web frameworks often want to
cache continuations. I'll have to t
On 6/19/07, Alaric Snell-Pym <[EMAIL PROTECTED]> wrote:
Hi folks,
I'm just assembling an egg to act a a memcached client.
Cool, that would be nice to have.
2) Write a second egg containing a Scheme-friendly API for caches.
This will involve a simple abstraction for caches, with 'null' (never
Hi folks,
I'm just assembling an egg to act a a memcached client.
Memcached is described here:
http://danga.com/memcached/
The memcached protocol is documented here:
http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt
It's a fairly simple text-commands-over-TCP job, but the
