PHPRedis fails on large values

[Pete Warden]

I'm just trying out Redis for the first time, awesome work, I love the
design decisions, but I got a very bad first impression after starting
with PHPRedis.

The punchline of the story is that PHPRedis has a fixed length 1024
character array to hold the results returned from the server. As soon
as the length of any value exceeded this, the socket parsing gets
terminally confused and spews errors continuously.

It took an hour of debugging unfamiliar code to reach this revelation.
I'm not sure I have time to get too deep on a fix, but I am going to
attempt to port the code from redis-cli.c to handle socket reading.

This is a pretty easy trap to fall into, so I think until there's a
proper fix it would be worth flagging PHPRedis as alpha/experimental
on the front page? I've also filed an issue to track the problem:
http://code.google.com/p/redis/issues/detail?id=108

cheers,
Pete
http://petewarden.typepad.com/

[Salvatore Sanfilippo]

On Fri, Nov 20, 2009 at 1:48 AM, Pete Warden <search...@gmail.com> wrote:
> I'm just trying out Redis for the first time, awesome work, I love the
> design decisions, but I got a very bad first impression after starting
> with PHPRedis.
>
> The punchline of the story is that PHPRedis has a fixed length 1024
> character array to hold the results returned from the server. As soon
> as the length of any value exceeded this, the socket parsing gets
> terminally confused and spews errors continuously.

Hello,

I leave to the PHPRedis author the reply as I'm not really familiar
with the implementation, but at the same time I want to suggest you a
pure-PHP client library that's very good even if new.

http://github.com/nrk/predis/

It supports the full set of Redis 1.1 commands, pipelining, consistent
hashing, and so forth.

> It took an hour of debugging unfamiliar code to reach this revelation.
> I'm not sure I have time to get too deep on a fix, but I am going to
> attempt to port the code from redis-cli.c to handle socket reading.

If you don't absolutely need a C extension I think the way to go is to
try a pure PHP library client, that is more hackable and IMHO not much
slower.

> This is a pretty easy trap to fall into, so I think until there's a
> proper fix it would be worth flagging PHPRedis as alpha/experimental
> on the front page? I've also filed an issue to track the problem:
> http://code.google.com/p/redis/issues/detail?id=108

Yes this is a good idea.

Cheers,
Salvatore

> cheers,
> Pete
> http://petewarden.typepad.com/
>
> --
>
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=.
>
>
>



--
Salvatore 'antirez' Sanfilippo
http://invece.org

"Once you have something that grows faster than education grows,
you’re always going to get a pop culture.", Alan Kay

[Nicolas Favre-Félix]

Hello,

My colleague Nasreddine Bouafif and I have been working on phpredis for a few weeks now, as part of our work. We've fixed LOTS of bugs, and have added a lot of methods as well. We now support values over 1024 bytes, containing new lines, and containing binary data (null bytes... think gzipped.)

We do believe that this extension is important, and our benchmarks showed an important difference in performance between a pure-PHP solution and this C code; We have also done our best to clean up the code, and support much more than the original code used to. We've contacted the original author several times, sending patches that have never been merged. I was supposed to add the last methods today in order to complete the list that Salvatore compiled to get a "1.0-ready" label, but you might as well get it now :-)

Our work is available on our corporate github account, this is where it'll always be: http://github.com/owlient/phpredis . We encourage developers to send us patches if they find bugs, or to suggest improvements. We are committed to supporting this client library. Once we support the last methods, I'd like to ask Salvatore to please add our link to the page.

We are still missing the following methods:

• select
• move
• dbsize
• auth
• save
• bgsave
• lastsave
• flushdb
• flushall
• sort
• info
• ttl

I'll start working on them right away. All the other ones ( http://gist.github.com/236822 ) are implemented and covered by unit tests.

For reference, there's much more now, but here is one of the changelogs we sent to the original author:

* Fixed many memory leaks - this was not a problem in the context of a web page, but the extension took too much RAM when we used it to insert thousands of items in redis with a command-line script. * Added the following functions: o lSet o setTimeout * Fixed several functions to make sure their return value is consistent with redis' own output (don't return nil for example, but false). * Added a command-formatting function (redis_cmd_format), with very limited printf-like support, in order to permit the storage of binary data. This is because strlen() and %s in spprintf will stop at the first null byte. We now allow binary data and provide tests for it. * Allowed for large return values (> 1024 bytes). This is a dynamic allocation which allows for large blobs of binary data. * Improved performance by getting rid of many lines that were copying data that was already available. * Used key_len and val_len when we can instead of calling strlen, since we have the values. * Changed variables from int to long when they were mapped using the letter “l” in zend_parse_method_parameters. * Read in a loop using php_stream_read instead of php_stream_gets, which stops at the first new line (that'd prevent you from storing multi-line data). * Fixed the multi-bulk reading, which had a problem with data starting with the $ sign. * Made sure that the value “nil” can be stored and returned without a problem. * Fixed all warnings. * Added tests and completed yours. Other points: * You will notice that we've kept the spprintf when the only parameters are keys and integers. The only time we've used redis_cmd_format is to append possible binary data to the command string. * It is our opinion that rPush should be implemented. lPush is not just “list push”, it is a “left” push, like rPush is a “right” push, so lPush with a flag to make it a right push seems counter-intuitive to us. Just like incr doesn't have a flag to make it a decr, if you will. * We've tried our best to keep your coding conventions, and we hope that the code is not messed up. It seems rather clear to us.

We look forward to people using this library. We've spent a lot of time fixing it, and are currently testing it for use in our production systems in the near future.

Nicolas Favre-Félix

2009/11/20 Salvatore Sanfilippo <ant...@gmail.com>

To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.

[Salvatore Sanfilippo]

2009/11/20 Nicolas Favre-Félix <n.favr...@gmail.com>:

> Hello,
> My colleague Nasreddine Bouafif and I have been working on phpredis for a
> few weeks now, as part of our work. We've fixed LOTS of bugs, and have added

Hello Nicolas,

that's great! I'm going to modify the home page and the
SupportedLanguages page right now to change the repository of the
project and to give credits to you.

Thanks!
Salvatore

[Aníbal Rojas]

Great,

Will update the SupportedLanguages draft page according would you
please give me the your Twitter accounts?

Best regards,

--
Aníbal Rojas
Ruby on Rails Web Developer
http://www.google.com/profiles/anibalrojas



2009/11/20 Nicolas Favre-Félix <n.favr...@gmail.com>:

[Salvatore Sanfilippo]

2009/11/20 Aníbal Rojas <aniba...@gmail.com>:

> Great,
>
>   Will update the SupportedLanguages draft page according would you
> please give me the your Twitter accounts?
>
>    Best regards,

Hello Anibal,

I already updated it! But indeed didn't linked the names of the new
contributors to a twitter account or web site, so +1 for your Q. about
the twitter account (or website).

Nicolas: we are very serious about giving credits, so if you like so
we can also backlink your company web page telling in the supported
languages page that the work was sponsored by xyz.

Other guys listening: we can do this for every other client lib of
patch. Just drop me a private mail or reply to this thread and I'll
try to do my best to give full credits.

Cheers,
Salvatore

[Nicolas Favre-Félix]

Salvatore,

Thank you very much for this publicity. Our company is Owlient: http://owlient.eu/

If you wish to add our emails to the page, please add the corporate ones: n.favr...@owlient.eu and n.bo...@owlient.eu

My twitter account is @yowgi, Nasreddine's doesn't have one.

Cheers,

Nicolas

2009/11/20 Salvatore Sanfilippo <ant...@gmail.com>

[Pete Warden]

That's awesome, thanks everyone, I'll download the new phpredis and give it a whirl.

Salvatore wrote:
> If you don't absolutely need a C extension I think the way to go is to
> try a pure PHP library client, that is more hackable and IMHO not much
> slower.

I've found a noticeable performance penalty when using Tokyo Tyrant through a pure PHP layer versus a C client, sounds like Nicolas has seen the same with Redis.

I also found Tyrant to be faster if I was using unix file sockets rather than TCP network sockets (eg something like /tmp/redis.sock rather than 6379). I don't see any support for that path in the code, has anyone looked at that?

cheers,
            Pete

2009/11/20 Nicolas Favre-Félix <n.favr...@gmail.com>

[Albert Lombarte]

Salvatore,

I'd like to ask if someone had a look at the new PHP client library I
sent you. Since it uses the __call method(), potentially can implement
any new methods you might add to the server. I still did not have the
time to start using REDIS in a proper way so my contribution cannot be
taken seriously yet ;)

Do you want me to upload the PHP library somewhere?

On 20 Nov, 17:07, Pete Warden <searchbrow...@gmail.com> wrote:
> That's awesome, thanks everyone, I'll download the new phpredis and give it
> a whirl.
>
> Salvatore wrote:
> > If you don't absolutely need a C extension I think the way to go is to
> > try a pure PHP library client, that is more hackable and IMHO not much
> > slower.
>
> I've found a noticeable performance penalty when using Tokyo Tyrant through
> a pure PHP layer versus a C client, sounds like Nicolas has seen the same
> with Redis.
>
> I also found Tyrant to be faster if I was using unix file sockets rather
> than TCP network sockets (eg something like /tmp/redis.sock rather than
> 6379). I don't see any support for that path in the code, has anyone looked
> at that?
>
> cheers,
>             Pete
>

> 2009/11/20 Nicolas Favre-Félix <n.favrefe...@gmail.com>

>
> > Salvatore,
>
> > Thank you very much for this publicity. Our company is Owlient:
> >http://owlient.eu/
> > If you wish to add our emails to the page, please add the corporate ones:

> > n.favre-fe...@owlient.eu and n.boua...@owlient.eu

>
> > My twitter account is @yowgi, Nasreddine's doesn't have one.
>
> > Cheers,
>
> > Nicolas
>

> > 2009/11/20 Salvatore Sanfilippo <anti...@gmail.com>
>
> >> 2009/11/20 Aníbal Rojas <anibalro...@gmail.com>:

> >> > Great,
>
> >> >   Will update the SupportedLanguages draft page according would you
> >> > please give me the your Twitter accounts?
>
> >> >    Best regards,
>
> >> Hello Anibal,
>
> >> I already updated it! But indeed didn't linked the names of the new
> >> contributors to a twitter account or web site, so +1 for your Q. about
> >> the twitter account (or website).
>
> >> Nicolas: we are very serious about giving credits, so if you like so
> >> we can also backlink your company web page telling in the supported
> >> languages page that the work was sponsored by xyz.
>
> >> Other guys listening: we can do this for every other client lib of
> >> patch. Just drop me a private mail or reply to this thread and I'll
> >> try to do my best to give full credits.
>
> >> Cheers,
> >> Salvatore
>
> >> > --
> >> > Aníbal Rojas
> >> > Ruby on Rails Web Developer
> >> >http://www.google.com/profiles/anibalrojas
>

> >> > 2009/11/20 Nicolas Favre-Félix <n.favrefe...@gmail.com>:

> >> >> Hello,
> >> >> My colleague Nasreddine Bouafif and I have been working on phpredis for
> >> a
> >> >> few weeks now, as part of our work. We've fixed LOTS of bugs, and have
> >> added
> >> >> a lot of methods as well. We now support values over 1024 bytes,
> >> containing
> >> >> new lines, and containing binary data (null bytes... think gzipped.)
> >> >> We do believe that this extension is important, and our benchmarks
> >> showed an
> >> >> important difference in performance between a pure-PHP solution and
> >> this C
> >> >> code; We have also done our best to clean up the code, and support much
> >> more
> >> >> than the original code used to. We've contacted the original author
> >> several
> >> >> times, sending patches that have never been merged. I was supposed to
> >> add
> >> >> the last methods today in order to complete the list that Salvatore
> >> compiled
> >> >> to get a "1.0-ready" label, but you might as well get it now :-)
> >> >> Our work is available on our corporate github account, this is where
> >> it'll

> >> >> always be:http://github.com/owlient/phpredis. We encourage

> >> developers to
> >> >> send us patches if they find bugs, or to suggest improvements. We are
> >> >> committed to supporting this client library. Once we support the last
> >> >> methods, I'd like to ask Salvatore to please add our link to the page.
> >> >> We are still missing the following methods:
>
> >> >> select
> >> >> move
> >> >> dbsize
> >> >> auth
> >> >> save
> >> >> bgsave
> >> >> lastsave
> >> >> flushdb
> >> >> flushall
> >> >> sort
> >> >> info
> >> >> ttl
>
> >> >> I'll start working on them right away. All the other ones (

> >> >>http://gist.github.com/236822) are implemented and covered by unit

> >> >> 2009/11/20 Salvatore Sanfilippo <anti...@gmail.com>
>
> >> >>> On Fri, Nov 20, 2009 at 1:48 AM, Pete Warden <searchbrow...@gmail.com

> >> >>> redis-db+u...@googlegroups.com<redis-db%2Bunsu...@googlegroups.com>
> >> .

> >> >>> For more options, visit this group at
> >> >>>http://groups.google.com/group/redis-db?hl=.
>
> >> >> --
>
> >> >> You received this message because you are subscribed to the Google
> >> Groups
> >> >> "Redis DB" group.
> >> >> To post to this group, send email to redi...@googlegroups.com.
> >> >> To unsubscribe from this group, send email to
>

> ...
>
> llegiu-ne més »

[Salvatore Sanfilippo]

On Sat, Nov 21, 2009 at 5:35 PM, Albert Lombarte <alom...@gmail.com> wrote:
> Salvatore,
>
> I'd like to ask if someone had a look at the new PHP client library I
> sent you. Since it uses the __call method(), potentially can implement
> any new methods you might add to the server. I still did not have the
> time to start using REDIS in a proper way so my contribution cannot be
> taken seriously yet ;)
>
> Do you want me to upload the PHP library somewhere?

Hello Albert!

I think Predis is using the same trick exactly but appears to be more
feature-complete. I think the best thing to do is to focus all on the
same client library that is at the moment the nearest to be a fully
featured and promising one, Predis in my opinion.

I hope you'll soon get a chance to apply Redis to your work!

Cheers,
Salvatore

[Albert Lombarte]

I agree, of course we should focus only in one library

I haven't tested Predis, when I did the library there was support for
PHP4 only. I'll have a look at it.

Thank you!

On 23 Nov, 00:21, Salvatore Sanfilippo <anti...@gmail.com> wrote:

> On Sat, Nov 21, 2009 at 5:35 PM, Albert Lombarte <alomba...@gmail.com> wrote:
> > Salvatore,
>
> > I'd like to ask if someone had a look at the new PHP client library I
> > sent you. Since it uses the __call method(), potentially can implement
> > any new methods you might add to the server. I still did not have the
> > time to start using REDIS in a proper way so my contribution cannot be
> > taken seriously yet ;)
>
> > Do you want me to upload the PHP library somewhere?
>
> Hello Albert!
>
> I think Predis is using the same trick exactly but appears to be more
> feature-complete. I think the best thing to do is to focus all on the
> same client library that is at the moment the nearest to be a fully
> featured and promising one, Predis in my opinion.
>
> I hope you'll soon get a chance to apply Redis to your work!
>
> Cheers,
> Salvatore
>
> --

> Salvatore 'antirez' Sanfilippohttp://invece.org

[Grégoire Welraeds]

Dear list,

Although I agree we should focus only in one library, as long as PRedis
is PHP 5.3 only, this can't be the only official PHP lib.
Support for the PHP 5.2 should be a commitment of the Redis PHP lib.
I know there are plan to adapt Predis to PHP < 5.3, I don't know what is
the priority of this feature request. IMHO, it should be a top priority
by now.
It would be nice if the Predis maintainer has a TODO list for this
target that he can share with us so that we can give some help.
Otherwise I'll have to stick with the old PHP lib with Redis 1.02.

Gregoire.

>> you�re always going to get a pop culture.", Alan Kay

>>
> --
>
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.

> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.

[Salvatore Sanfilippo]

2009/11/23 Grégoire Welraeds <gregoire...@gmail.com>:

> Dear list,
>
> Although I agree we should focus only in one library, as long as PRedis
> is PHP 5.3 only, this can't be the only official PHP lib.
> Support for the PHP 5.2 should be a commitment of the Redis PHP lib.

Yep I agree about this, but I think Alessandro is trying to fix the
issue. Btw as I consider this a priority I'm willing to help and will
try to do the port myself in short time if needed.

Alessandro: for instance to drop support for pipelining and consistent
hashing for 5.2 as a temporary fix is perfectly acceptable IMHO. Is
this solution viable?

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo
http://invece.org

"Once you have something that grows faster than education grows,

you’re always going to get a pop culture.", Alan Kay

[Grégoire Welraeds]

On 23/11/2009 10:46, Salvatore Sanfilippo wrote:
> 2009/11/23 Gr�goire Welraeds <gregoire...@gmail.com>:

>> Dear list,
>>
>> Although I agree we should focus only in one library, as long as
>> PRedis is PHP 5.3 only, this can't be the only official PHP lib.
>> Support for the PHP 5.2 should be a commitment of the Redis PHP
>> lib.
>
> Yep I agree about this, but I think Alessandro is trying to fix the
> issue. Btw as I consider this a priority I'm willing to help and
> will try to do the port myself in short time if needed.

I'm also willing to help.

>
> Alessandro: for instance to drop support for pipelining and
> consistent hashing for 5.2 as a temporary fix is perfectly acceptable
> IMHO. Is this solution viable?

Salvatore,Alessandro,
As I'm looking into PRedis code right now, I see that it use PHP 5.3 namespace feature.
EG: $redis = new Predis\Client(REDIS_HOST, REDIS_PORT);
To support 5.2, I suppose that we should� start by removing the namespaces
EG: $redis = new predis_Client(REDIS_HOST, REDIS_PORT);
Which probably means that we should change almost all files, and probably have two target tarball:
one for PHP5.3, and the other for PHP5.2.

cheers,
Gr�goire.

[Salvatore Sanfilippo]

2009/11/23 Grégoire Welraeds <gregoire...@gmail.com>:

> Salvatore,Alessandro,
> As I'm looking into PRedis code right now, I see that it use PHP 5.3
> namespace feature.
> EG: $redis = new Predis\Client(REDIS_HOST, REDIS_PORT);

> To support 5.2, I suppose that we should  start by removing the namespaces

> EG: $redis = new predis_Client(REDIS_HOST, REDIS_PORT);
> Which probably means that we should change almost all files, and probably
> have two target tarball:
> one for PHP5.3, and the other for PHP5.2.

Ok, as I'm not familiar with the recent PHP changes, I wonder if the
use of namespaces represent a real win or if it's just possible to
drop this changes from the 5.3 port as well in order to avoid
maintaining two different codebases.

Cheers,
Salvatore

>
> cheers,
> Grégoire.

>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to
> redis-db+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/redis-db?hl=.
>

[Grégoire Welraeds]

On 23/11/2009 10:58, Salvatore Sanfilippo wrote:
> Ok, as I'm not familiar with the recent PHP changes, I wonder if the
> use of namespaces represent a real win or if it's just possible to
> drop this changes from the 5.3 port as well in order to avoid
> maintaining two different codebases.
>
> Cheers,
> Salvatore
>

My take is that
- Just because of its currently limited feature (PHP 5.3), namespaces
support is a nice to have feature but surely not a requirement.
- For the sake of simplicity, I agree that we should only have one target.
Gr�goire

[Daniele Alessandri]

2009/11/23 Grégoire Welraeds <gregoire...@gmail.com>:

Hi Grégoire,

> I know there are plan to adapt Predis to PHP < 5.3, I don't know what is
> the priority of this feature request. IMHO, it should be a top priority
> by now.

I had not announced a roadmap about this issue because I did not know
how much attention Predis would have gotten after releasing its code
on github. This basically means that the priority of a backport of
Predis to PHP 5.2 will be decided by community interest/request.

Just to be clear, I have started Predis to fulfill my own needs so it
is still being modeled and developed in a couple of environments where
the switch to PHP 5.3 has already been made. I am firm that PHP 5.3 is
the future of PHP and it should be adopted as soon as possibile, but I
know that it will not be so easy and quick for everyone to migrate,
which also means that supporting PHP 5.2 is indeed mandatory at this
stage.

Having said that, what is keeping me from backporting Predis right now
is the fact that I am still finalizing its internals, but I am almost
done with that. As a result of this work, support for pipelining
should be easily portable to a 5.2 version even without anonymous
functions. I still need to investigate the client-side sharding bits
though. Namespaces could be easily replaced by the usual underscore
convention, the only entry point for the end-users is Predis\Client
after all. Managing two different codebases should not be too much of
a pain with such premises (and I am willing to maintain both anyway),
a strong test suite will surely help. I am just strongly biased
towards a not crippled version of Predis that can exploit some of the
new features of PHP 5.3, but designed in a way that makes it easy to
maintain a codebase that targets early versions of the language.

I am completely open to hear your opinions, and the ones from the rest
of the list :-)

--
Daniele Alessandri
http://twitter.com/JoL1hAHN
http://www.clorophilla.net/blog/

[Salvatore Sanfilippo]

On Mon, Nov 23, 2009 at 12:39 PM, Daniele Alessandri
<suppa...@gmail.com> wrote:

> Having said that, what is keeping me from backporting Predis right now
> is the fact that I am still finalizing its internals, but I am almost
> done with that. As a result of this work, support for pipelining
> should be easily portable to a 5.2 version even without anonymous
> functions. I still need to investigate the client-side sharding bits

Hello Daniele,

my feeling is that client-side sharing while very interesting is
something that may be ported in a second time if it's a problem. Thank
you for your efforts in Predis, I'll push this lib in the Redis
community as I think it is a piece of code that can reach the quality
of the other top quality client libs like Ruby and Java are IMHO.

I'm very happy we are fixing the problems in the PHP and Python side
as this languages are very used but were not very well supported in
the past.

Another promising library client is the Go language one AFAIK.

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo
http://invece.org

"Once you have something that grows faster than education grows,

you’re always going to get a pop culture.", Alan Kay

[Daniele Alessandri]

On Mon, Nov 23, 2009 at 12:45, Salvatore Sanfilippo <ant...@gmail.com> wrote:

Salvatore,

> my feeling is that client-side sharing while very interesting is
> something that may be ported in a second time if it's a problem. Thank

My guess is that the client-side sharding part could actually work on
PHP 5.2 as is, with just a couple of minor changes. It is just that I
have not looked into that yet but, indeed, it is not a top priority.

> Another promising library client is the Go language one AFAIK.

On a (not so completely) unrelated note, I think that it would be
great at some point to have a top-quality C client library that could
be leveraged by projects like phpredis as a solid base.

[Salvatore Sanfilippo]

On Mon, Nov 23, 2009 at 2:40 PM, Daniele Alessandri
<suppa...@gmail.com> wrote:
> On Mon, Nov 23, 2009 at 12:45, Salvatore Sanfilippo <ant...@gmail.com> wrote:
>
> Salvatore,
>
>> my feeling is that client-side sharing while very interesting is
>> something that may be ported in a second time if it's a problem. Thank
>
> My guess is that the client-side sharding part could actually work on
> PHP 5.2 as is, with just a couple of minor changes. It is just that I
> have not looked into that yet but, indeed, it is not a top priority.

Ah ok! Sorry didn't understood this well enough.

> On a (not so completely) unrelated note, I think that it would be
> great at some point to have a top-quality C client library that could
> be leveraged by projects like phpredis as a solid base.

Indeed, I guess I'm a good candidate for writing it... I'll try to do
it after the 1.1 release.
Other huge needs are tools for JSON export and so forth, but it's very
hard to stay in line with the TODO list.

Currently I'm implementing epoll in ae.c as it was really about time.
An 1.1 without such a feature is going to be a strong real-world
adoption problem since there are a few cases where it's important to
take a lot of connections at the same time against Redis (but if you
want to know what I think, I'm all for timing out connections after a
few seconds of inactivity in such scenarios). Still is a
psychologically blocking thing, if redis is not known to scale to a
lot of concurrent clients there are important places were it will
never be adopted.

[Daniele Alessandri]

On Mon, Nov 23, 2009 at 16:04, Salvatore Sanfilippo <ant...@gmail.com> wrote:

>> On a (not so completely) unrelated note, I think that it would be
>> great at some point to have a top-quality C client library that could
>> be leveraged by projects like phpredis as a solid base.
>
> Indeed, I guess I'm a good candidate for writing it... I'll try to do
> it after the 1.1 release.

Well, I was actually thinking about a kind contribute from a
community-driven project, you already have a lot of work to take care
of with the server part :-) Unfortunately I can't include myself
because my C skills are rusty (just to use an euphemism).