> 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 -~----------~----~----~----~------~----~------~--~---
