Hi Jim, FWIW, mod_pagespeed has a redis interface in C++, and is based on hiredis <https://github.com/redis/hiredis/tree/010756025e8cefd1bc66c6d4ed3b1648ef6f1f95> .
It's all in https://github.com/pagespeed/mod_pagespeed/tree/master/pagespeed/system . https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache.h https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache.cc https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_cluster_setup.cc https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_cluster_setup.h https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_cluster_setup_main.cc https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_cluster_test.cc https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_test.cc Important questions about Redis strategy-- beyond which underlying API to use -- arise with handling clustering or other mechanisms to have more than one server. For mod_pagespeed we chose clustering, which is a little bit more complicated than the apr_memcache equivalent, because it allows configurations to dynamically update. -Josh On Wed, Nov 2, 2016 at 8:20 AM, Jim Jagielski <j...@jagunet.com> wrote: > OK, so my plan is to start pulling the relevant bits out of Credis for > use in apr_redis. I was thinking initially about maybe just using the > library, but for parity w/ apr_memcache, that doesn't make sense. > > Here's the rub: I'd prefer not having to do both the 1.6 and 2.0 > "ports" at the same time; instead I'd like to implement 1st in 1.6 > and then, once it gets the green light front-port it to 2.0. The > issue, of course, is that 1.6 still has apr and apr-util. > > Any concerns about this approach? Or would people prefer it be > added 1st to 2.0/trunk and then folded into 1.6... >
