bbangert/retools — Issue #4: Unify dogpile.cache and retools
Author: ergo
Created: 2011-12-14 15:13:01+00:00
State: open

Now that we have beaker, retools and dogpile.cache by zzzeek, maybe it would be a good idea to implement retools caching as dogpile extension? So we avoid fragmentation across solutions.
````
31<Ergo^>30 zzzeek, hey zzzeek so whats the status on beaker/retools/dogpile situation
31<Ergo^>30 is there any chance that dogpile and retools could get unified at some point? It seems that we get multiple caching solutions that do the same
31<Ergo^>30 (with some exceptions ofc)
19* 19rmarianski (~rmariansk@mail.marianski.com) has joined #pyramid
18<19zzzeek> ive no idae what retools is
31<Ergo^>30 hm, i think ive showed you - ben wrote a beaker drop in replacement for redis
31<Ergo^>30 + work queue - so it also serves as replacement for celery
31<Ergo^>30 zzzeek, https://github.com/bbangert/retools
23* 23merde has quit (23Ping timeout: 240 seconds23)
31<Ergo^>30 so currently we have beaker, retools and dogpile what roughly do the same - not debating implementation details here
18<19zzzeek> oh that thing
18<19zzzeek> well yes he'd build a backend that's for dogpile.cache
18<19zzzeek> he can leave it as retools
18<19zzzeek> and just provide a plugin
23* 23mr_jolly (23~simon@58.137.222.50) has left #pyramid
18<19zzzeek> this is what is awsome about dogpile.cache, there is *nothing* there practically
18<19zzzeek> its like, an interface, and a little code, and that's it
````