apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: apr_redis
Date Wed, 02 Nov 2016 15:01:04 GMT
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 <minfrin@sharp.fm> wrote:
> 
> On 02 Nov 2016, at 2:20 PM, Jim Jagielski <jim@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
> —
> 


Mime
View raw message