Memcache options for Drupal 6.x - your opinions please

At this point, Cache Router uses no code from the original memcache project. I rewrote everything for memcache handling. I am working on the session code now for Cache Router, and it uses no code from my original implementation for memcache either.

The switch between the two modules is very trivial. You just change your settings.php and you are done. Very basic. The configurations are different, but both are well documented. I've launched a site with memcache and switched to Cache Router once I had the code base more stable. It was a breeze :)

HTH.

Steve

My primary driver was the ability to support multiple cache engines. When I started writing it, it was going to be more proof of concept, but Memcache API didn't have a 6.x branch so I decided to just start from scratch so I could use OO code and not have ties to legacy code that wasn't being actively developed. Also, none of the modules that I wanted to use had an easy way to "drop in" with the way that cache router works, so I just rewrote most everything. I was initially inspired by the way CakePHP handles this. It has all the same engines I have, and they are built into it's platform. I think that is the correct direction to go.

Since I started the project, John VanDyk and Jeremy Andrews have stepped up and taken over the Memcache API project. I had borrowed small bits of Memcache code, but it was mostly stuff I had written to start with. I didn't like the way a couple things were being done, and I didn't want to slow down development of Cache Router because of waiting for the community to make changes to Memcache API module. The 5.x branch was a "backport" of Cache Router, and to this day still lags slightly on development from 6.x branch. I just haven't put as much effort into it cause 6.x is now, and D7 is the future. 5.x has cache serialization issues that I solved for 6.x and is a pain cause you need to not only patch core with my provided patches, but you also should technically patch every contrib module in order for it to be effective. 5.x support will be dropped eventually, but I will continue to try to maintain it even into 7.x release cycle.

Memcache API is a great module and I have used it many, many times. There is some level of disagreement in the community about Cache Router, because some people think it should be more modular and let other modules implement the engines. While in theory this sounds great, I can only guarantee the performance of the module when I am working on the code and don't want to delay it's adoption or bug fixes in waiting for other projects to catch up. With that said, if any of the other module Maintainers that inspired Cache Router wanted to join in the development, they are more than welcome to.

I feel strongly that what the end users in the community want and what developers want differs significantly. Drupal developers want to have a zillion tiny independent modules that can be mixed and matched at will. This is good, but often leads to headaches for end users. End users want to install Cache Router, use whatever engine they want, never think about it again until update status tells them to update. For me, end users being happy is more important that making everyone in the Drupal development community happy. I want people to use Drupal to make cool websites and when they can scale without thinking about it, it makes them concentrate on their business, and not filing bug reports.

Steve