Drupal 7 APC Cache backend

To make a summary, you want to do something with Slantview's project he does not want to do, and you are asking us to make you co-maintainer.

Something does sound right, to me. We cannot force a mantainer to do what he does not want to do, if it is not a security, or license issue; we cannot make you co-maintainer just because the current maintainer has a different opinion about the code to develop.

From #1, it seems like you have contacted slantview by email, but it is not clear what was the conclusion of this email conversation.

I will talk to slantview so he understands there is no point in continuing cacherouter.

See #593238: Do not release Drupal 7 version of this and move the engines into separate projects

I gave him commit access to APC module, but as I stated in #593238: Do not release Drupal 7 version of this and move the engines into separate projects I think APC should be part of core, maybe we can all work to make that happen and get rid of the contrib module altogether. If you guys want to make him maintainer I have no objections to that, I would like to continue to help out on it if that is the direction that we are going to go in. I personally think splitting up all these cache modules into separate modules is a pain for end users. Having APC, Memcache, File and DB caching in core seems like a better plan. I will convert my engines and try to get them into core, but I will definitely need other performance minded people on board with this plan. Dries has previously stated that he would like to see additional cache engines in core. I will open a new issue and work on that seperately.

The ultimate goal for cache router was to get the engines into core and let cache router be an addon that will allow you to use multiple engines simultaneously. I haven't had time to provide patches for core, but I still think this would be a great plan. The reason I replied and said I would rather see the work in cache router is because I already have working implementations, and I would hate to see yet-another-fork of the code. This has already happened several times, most notably with the "Cache" module (http://drupal.org/project/cache) and the authcache module (http://drupal.org/project/authcache). Authcache has since removed the Cache Router code and I think that moving these engines to core would allow better coverage and more people to test.

chx rewrote the Cache API for D7, but one of the biggest roadblocks for writing a coherent cache api (cache_clear_all) has not changed at all. This function needs to go away and be reworked into standard patterns (cache_delete, cache_flush_all, cache_flush_temporary). We are overriding the function to do different things based on what parameters are passed in and it is not clearly documented how it should work. Contrib module developers have continually messed this up and clear caches that are unnecessary based on a misunderstanding to what to pass into this function.

Sorry for the rant, but these are the reasons I didn't want to start down the APC module path again. More time before this can actually go into core. More beta releases, and further from getting to a destination for this code. Cache Router will have a 1.0 official release in October. I have been hired to build out functionality to bring it into a bigger project so that it can be more widely deployed. I wanted to take the code from this final release, and repackage the engines as DrupalCacheInterface classes for D7 and try to get them committed into core.

Also, we still have code slush so you are welcome and was welcome during the last two years to improve the cache system. I have not heard from you that this is the problem with the cache system nor I did from anyone else.

@chx - I intend to, and not to be a jerk, but I've emailed you privately and never heard a response about working on core caching, and I've been working on Cache Router in the open it's not a secret what I've been doing. It's listed in plain english on the project page that I would like to see that technology in core.

Everyone else that I emailed about putting together efforts at Drupalcon DC (last Drupalcon I was able to attend) was uninterested in combining efforts on cache router and memcache.

As far as not hearing from anyone else that this is a problem and basically discounting my statement, here is a reference for you. In John VanDyk's session in DC he specifically calls out the issue of how we override cache_clear_all to do too many things (ref. http://www.archive.org/details/DrupalconDc2009-InsideDrupalCachingFromSt...) see about 11:30 marker when he starts talking about cache_clear_all and specifically has a title that says "Yikes!".

As far as the last two years, I have maintained memcache api prior to you, i wrote the initial session handling for memcache api, i wrote cache router, and the Drupal 5 cache serialzation patch. I don't appreciate you acting like I haven't been active with this stuff. I was intending to rewrite cache api for Drupal 7 but you got to it before I did.

I will get to work on this as soon as my schedule permits. Glad to see that what efforts everyone else puts into Drupal goes unnoticed. Just because I'm not some Drupal rockstar like yourself doesn't mean I don't spend a lot of time trying to make it better. I hope you feel justified that you can make me feel like shit about the thousands of hours in Drupal development I've done in two sentences, great community leaders we have here.

Thanks.

I made a mess here and I am truly sorry. I have indeed forgot that you wrote #137415: cache serialization. Please accept my apologies, OK?

Apology accepted.

As the OP has been made co-maintainer, I think this report can be considered fixed.