Check out Beaker if you haven't already. It's WSGI middleware for sessions and caching that is basically broken out from Myghty and supports memcached.On Oct 3, 2006, at 8:42 AM, lateef jackson wrote: +1
A project I worked on implemented some caching abstraction. There where basically 2 options Cache and TimedCache. Cache was an open ended cache where the caching system would evict objects as it needed the space. TimedCache was a cache that would expire after a specific amount of time. Generally we used the TimedCache for web content that rarely changed. Note: objects that went into the open ended cache would also need to have code that invlidated those objects.
We had 2 providers of back end caching memcache (http://www.danga.com/memcached/) and lrcucache (http://freshmeat.net/projects/lrucache/ ). Simplified Dict interface. Only supports 'in', setitem, and getitem, delitem.
memcached is really a wonderful piece of software but only if you need it. You can probably get away with a simpler caching system if you are only running 1 TG instance and don't need to share the cache with anything outside of TG.
On 10/3/06, Stuart Clarke <[EMAIL PROTECTED]> wrote:
> 2. From what I've read, memcached is cool. And is the one true solution
> for caching a scalable web application. I plan to use memcached to
> cache the DB content of my TG app. Question: does Identity support
> caching with memcached (from looking at the code, I suspect not)? Are
> there plans to introduce this? Does anyone else want it? I'm thinking
> of a system wherein, if it's not already there, the identity information
> for a particular user ID is placed in memcached (this goes for session
> IDs too), indexed by one of the unique keys (possibly username?). When
> the user accesses a page, their credentials are compared to the
> memcached data. If new data for that ID is written to the DB, or
> deleted from the DB, the associated memcached content would be updated
> or deleted accordingly.
Addendum: TG would probably benefit from a generic caching mechanism,
which would apply to all object data. A cache API could be implemented,
and then used by Identity and whatever else wants to. We could then
have several implementations behind the API: disk, local memory,
memcached, none. The cache used by Identity would be selectable and
tuneable from the config files. One could also create (potentially
several different) cache instances to use in other parts of ones app.
What do people think?
Stuart
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears
-~----------~----~----~----~------~----~------~--~---
|
