That's my thought as well... Due to the apr/apr-util combination in 2.0, it's actually easier to add to 1.6 and then port to 2.0 (since apr_redis is in apr-util), then the reverse (and typical method).
Any idea why we are using apr_socket_sendv() in apr_memcache? Using apr_socket_send() would be easier but maybe for parity I should continue w/ the vecs. Also, unless people have an issue, I prefer using the "telnet" method for the client (ala Credis) rather than the more cumbersome method. > On Nov 2, 2016, at 9:45 AM, Graham Leggett <minf...@sharp.fm> wrote: > > On 02 Nov 2016, at 2:20 PM, 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... > > I’m imagining that it’s easier to work with apr-util v1.6 + httpd than apr > v2.0 + httpd? If so it makes sense. Can’t release v1.6.x until it’s also in > v2.0 though, but that shouldn’t be too much of a problem. > > Regards, > Graham > — >
