On Apr 9, 2012, at 11:49 AM, Wichert Akkerman wrote:
> On 2012-4-9 17:28, Michael Bayer wrote:
>> There's a decent README up now at http://pypi.python.org/pypi/dogpile.cache
>> and you can read all the docs at http://dogpilecache.readthedocs.org/. I'm
>> hoping to get some testers and initial feedback.
>
> Can you shed some light on how this differs from retools
> (http://readthedocs.org/docs/retools/en/latest/), other than that dogpile
> does not support redis and retools only supports redis?
>
Basically the caching and distributed locking features of retools should be a
dogpile backend, and in fact they can be if retools wants to publish a
dogpile.cache backend. Though looking at the source he'd have to rip out
some more rudimental functions out of CacheRegion.load(), which seems to be
totally inlined right now. The redis lock itself could be used but needs a
"wait" flag.
It seems like we'd almost be better off taking the "stats" logic wired into
"load" and just making that an optional feature of dogpile, so that all the
backends could get at hit/miss stats equally. The get/set/lock things i see in
retools would only give us like a dozen lines of code that can actually be
reused, and putting keys into redis and locking are obviously almost the same
as a memcached backend in any case. It's just a question of, which project
wants to maintain the redis backend.
He appears to have a "region invalidate" feature taking advantage of being able
to query across a range in redis, that's not something we can generalize across
backends so I try not to rely on things like that, but dogpile can expose this
feature via the backend directly.
The function decorators and the dogpile integration in retools are of course
derived from Beaker the same way dogpile's are and work similarly. Dogpile's
schemes are generalized and pluggable.
It seems like Ben stuck with the @decorate("short-term", "namespace") model we
first did in Beaker, whereas with dogpile.cache though the API looks more like
flask-cache (http://packages.python.org/Flask-Cache/), where you have a "cache"
object that provides the decorator.
Queue/job/etc appears to be something else entirely, I'd ask how that compares
to celery-redis and other redis-queue solutions.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
