On 10/31/2016 02:43 PM, Jim Jagielski wrote: > It would, but that would mean even more of a APR dependency > and a wait until the next release of APR and etc, etc, etc... > Basically, APR moves too slow for httpd.
Which creates the generic question for me: Can't we setup APR in a way that for certain aspects we could compile "drivers" against an existing APR whose code exists outside of APR first and gets part of standard APR later easily? I guess the redis stuff does not necessarily qualifies for this idea yet, because we have no caching backend API defined in APR yet that would allow to just plugin different drivers / providers (memcache does not seem to have a genric API defined yet). Regards Rüdiger > >> On Oct 31, 2016, at 9:34 AM, Graham Leggett <minf...@sharp.fm> wrote: >> >> On 31 Oct 2016, at 3:30 PM, Jim Jagielski <j...@jagunet.com> wrote: >> >>> Query: Think it would be worth my time to work on a >>> Redis implementation for mod_cache/mod_socache? I am >>> working on a minimal Redis lib, related to work, which >>> is basically a soft reboot of Credis from GoogleCode, >>> which could serve as the core functionality, which is >>> what got me thinking about it. >> >> Would it fit better as an APR-util module? If so, mod_cache_socache could >> use it unmodified. >> >> Regards, >> Graham >> — >> > >
