This is in regards to Tickets #11675 and #12427.
Review of the problems ----- There are two overarching problems with Django's current implementation of memcached as a backend: A) The import tree method of picking the appropriate library (if I have cmemcache use it, if not use python-memcache, if not throw an error). B) Open support for the retired and buggy cmemcache (see http://gijsbert.org/cmemcache/) Both tickets are marked as DDN and while the two tickets are slightly orthogonal, there seems to be a united solution: a more explicit and inclusive method for picking a memcached library. With this in place, deprecating out cmemcache because it is not longer supported is easy as picking the milestones for deprecation and removal. Including cmemcache, there are currently four major libraries for accessing memcached: python-memcache, cmemcache, python-libmemcache, and pylibmc. A few details on these along with speed benchmarks can be found here: http://amix.dk/blog/viewEntry/19471 Proposed Solution ------ A slight rework of the memcache client that implements a base class which resembles the current Django 1.1 memcache client. Anything that implements the current CACHE_BACKEND setting "memcached://server:port" would use this base class. Throw a deprecation warning if the cmemcache library is being used in this way. Additionally, add explicit subclasses for pylibmc and python- libmemcache, so if "pylibmc://server:port", "memcached://server:port? lib=pylibmc" or some variety there of controls what subclass gets used. Forcing the user to be explicit on what library they use could be added later, although I don't know if it's necessary. Pylibmc and python-memcache have almost identical API characteristics (from pylibmc's docs: "pylibmcâs interface is intentionally made as close to python-memcached as possible, so that applications can drop- in replace it."), and only differ in pylibmc's flexibility of memcache behaviors and their hashing method. (See http://sendapatch.se/projects/pylibmc/#behaviors and http://sendapatch.se/projects/pylibmc/#differences-from-python-memcached). The subclass should end up being fairly lightweight. I also am only partially familiar with python-libmemcache, so if anyone can speak to key differences in implementation, it would be very handy. Hopefully this is enough of a discussion to get the ball rolling. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
