Developers should able to controls throttling on api requests

[gone]

Perhaps using throttle decorator? Or some attribute of the APIDocument?

[j2labs]

This is a good idea. Considering it's normal for Python systems to run multiple Python processes I don't believe we can do this without something of a shared memory resource containing the access information.

Redis is my first choice for shared memory. If Brubeck takes an opinion and decides that Redis is the best way to share memory between independent processes we could probably also provide a Redis based session / cache layer. I think that would be helpful as the current offer is a very basic in memory store, which isn't useful for the same reasons I describe above.

What are your thoughts?

[0x1997]

I'm also looking forward to Redis based session support in Brubeck.

[j2labs]

I think this is a neat idea.

What do you think of the brubeck.caching module? If that was updated to use Redis, would you have what you need?

On Mar 10, 2012, at 2:03 AM, 0x1997 reply@reply.github.com wrote:

I'm also looking forward to Redis based session support in Brubeck.

---

Reply to this email directly or view it on GitHub:
#32 (comment)

[kracekumar]

@j2labs : Forcing users to use redis based cache support will divide the group, brubeck should offer extensions like support to redis cache, some users want to use memcache and other like to use beaker. Keep brubeck core small, create more extensible like extensions or addons, today redis is talk of the hour, tomo something else.

[j2labs]

I agree with your thinking, Krace.

A common interface with an external module that provides the opinions. :)

I believe @sethmurphy is interested in working on a Redis query set. When that's complete, we could use it for this too.

On Mar 10, 2012, at 10:31 AM, kracekumar reply@reply.github.com wrote:

@j2labs : Forcing users to use redis based cache support will divide the group, brubeck should offer extensions like support to redis cache, some users want to use memcache and other like to use beaker. Keep brubeck core small, create more extensible like extensions or addons, today redis is talk of the hour, tomo something else.

---

Reply to this email directly or view it on GitHub:
#32 (comment)

[0x1997]

@j2labs I haven't tried brubeck.caching yet. As for Redis based cache, retools seems a good choice.

[j2labs]

Retools looks like an awesome head start.

I wonder if brubeck.caching provides an abstract enough interface that it could have retools caching underneath it...?

I'd like to see a uniform interface for Brubeck emerge so we can support multiple caches with minimal work.

On Mar 10, 2012, at 11:29 AM, 0x1997 reply@reply.github.com wrote:

@j2labs I haven't tried brubeck.caching yet. As for Redis based cache, retools seems a good choice.

---

Reply to this email directly or view it on GitHub:
#32 (comment)

[sethmurphy]

I think that a queryset interface used in a core caching mechanism would be a good approach.

It may be nice for some to be given an opinion on what to use if they wish to have a distributed solution instead of forced to make their own, while at the same time allow more advanced architects to choose, or write part of, their own solution. I think Redis would be a good default opinion. They could also be given the option of using a dict queryset if they are only running one instance.

@j2labs: Could this be baked into caching.BaseCacheStore by simply using the queryset.DictQueryset instead of dict for the moment? Then specific querysets could be used to specify the storage engine.