Redis 1.1 plans and client libraries removal from the Redis distribution

10 views
Skip to first unread message

Salvatore Sanfilippo

unread,
Oct 27, 2009, 2:30:19 PM10/27/09
to Redis DB
Hello all!

this email is about two matters, the first is the plans for Redis 1.1,
that are going to change a bit compared to what I had in mind. The
second issue is about the fact that Redis is currently including
source code of client libraries in the Redis server distribution, and
it's something I could like to change too.

Redis 1.1 roadmap:

Compared to Redis 1.0 the 1.1 version of Redis already includes some
important change:

a) In memory integer encoding of integers. A pretty big memory saving,
20% or more with datasets using a lot of IDs.
b) MSET and MSETNX
c) SRANDMEMBER and many little fixes.
d) Sorted Sets (zsets) and all the commands to deal with this new data
structure.
c) Redis is now Solaris compatible.

I think it's a good idea to release Redis 1.1 with just this features,
delaying hashes for Redis 1.2, so what I've in mind is to develop a
litte further ZSets and feature freeze the code, start stress testing
Redis, releasing the first 1.1-beta tar.gz, and finally release Redis
1.1-stable in about one/two months since now.
In the meantime it's really important to have most client libs 1.1
read (MSET with the new protocol, Z-commands, and so on).

About client libraries inclusion in the Redis tarball, this was a good
move in the early days of Redis because it's a way to make early
adopters happy. Not that now the "early adopters" stage finished,
Redis continues to be a very young project less than 1 year old, but
it starts to have a user base, client libs start to be too much, and
after all to download a tar.gz more is not that hard ;) So I could
like to stop the inclusion of the client libs, with the exception of
the Tcl client lib that is used in order to run the test-redis.tcl
script. Please if you think this is not a good idea ping me as this is
not written in the rocks :)

I think that a more bazar-oriented client lib development process may
lead to best results. For instance a decent PHP client library ;)
There are N libs and no one appears to be good enough, that's starting
to be a bad selling point for Redis.

Btw once client libs are removed from the tar.gz how they'll be
advertised? In two ways: in the Redis home page, like it already
happens, and in the README file inside the client-libraries directory
that will, indeed, point to the Redis home page.

Thanks for any feedback.

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

Aníbal Rojas

unread,
Oct 28, 2009, 1:37:36 PM10/28/09
to Redis DB

Salvatore,

> Compared to Redis 1.0 the 1.1 version of Redis already includes some
> important change:
>
> a) In memory integer encoding of integers. A pretty big memory saving,
> 20% or more with  datasets using a lot of IDs.

This is interesting, so building Redis from devlopment head we should
see a memory improvement. I think I will do the test. Question: Are
the database files binary compatible? Can I use a 1.0 DB, and use it
to start a HEAD Redis instance?

> d) Sorted Sets (zsets) and all the commands to deal with this new data
> structure.

Same question regarding binary compatibility of new dump files...

> I think it's a good idea to release Redis 1.1 with just this features,
> delaying hashes for Redis 1.2, so what I've in mind is to develop a
> litte further ZSets and feature freeze the code, start stress testing
> Redis, releasing the first 1.1-beta tar.gz, and finally release Redis
> 1.1-stable in about one/two months since now.

+1

> About client libraries inclusion in the Redis tarball, this was a good
> move in the early days of Redis because it's a way to make early
> adopters happy. Not that now the "early adopters" stage finished,
> Redis continues to be a very young project less than 1 year old, but
> it starts to have a user base, client libs start to be too much, and
> after all to download a tar.gz more is not that hard ;) So I could
> like to stop the inclusion of the client libs, with the exception of
> the Tcl client lib that is used in order to run the test-redis.tcl
> script. Please if you think this is not a good idea ping me as this is
> not written in the rocks :)

When languages use their own package system, it doesn't make sense to
have the libs hanging around. In the case of Ruby client, we won't use
other than a gem to ease the management of the box.

> Btw once client libs are removed from the tar.gz how they'll be
> advertised? In two ways: in the Redis home page, like it already
> happens, and in the README file inside the client-libraries directory
> that will, indeed, point to the Redis home page.

Talking about reaching a 1.1 another point to add into the plans is
the information in the site, if you need help I will be glad to
collaborate reviewing it. I have seen a lot of information in the
Google Group that should be included into the side.

Best regards,

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

Salvatore Sanfilippo

unread,
Oct 28, 2009, 1:46:53 PM10/28/09
to redi...@googlegroups.com
2009/10/28 Aníbal Rojas <aniba...@gmail.com>:

>
>
> Salvatore,
>
>> Compared to Redis 1.0 the 1.1 version of Redis already includes some
>> important change:
>>
>> a) In memory integer encoding of integers. A pretty big memory saving,
>> 20% or more with  datasets using a lot of IDs.
>
> This is interesting, so building Redis from devlopment head we should
> see a memory improvement. I think I will do the test. Question: Are
> the database files binary compatible? Can I use a 1.0 DB, and use it
> to start a HEAD Redis instance?

Yes, you can take a Redis 1.0 database and start a Redis 1.1 server
without troubles.

>> d) Sorted Sets (zsets) and all the commands to deal with this new data
>> structure.
>
> Same question regarding binary compatibility of new dump files...

New dump files produced with Redis 1.1 can be used in Redis 1.0 as
long as there are no ZSets inside. Otherwise Redis 1.0 will abort
while loading the dataset.


> When languages use their own package system, it doesn't make sense to
> have the libs hanging around. In the case of Ruby client, we won't use
> other than a gem to ease the management of the box.

Indeed! And to take this in sync is work that can be used to improve
the server instead.

>> Btw once client libs are removed from the tar.gz how they'll be
>> advertised? In two ways: in the Redis home page, like it already
>> happens, and in the README file inside the client-libraries directory
>> that will, indeed, point to the Redis home page.
>
> Talking about reaching a 1.1 another point to add into the plans is
> the information in the site, if you need help I will be glad to
> collaborate reviewing it. I have seen a lot of information in the
> Google Group that should be included into the side.

Indeed... the documentation should be improved a lot. I'll be very
glad if you can help with this. Even a single line of documentation is
something. Today I put the documentation for the Z-commands in the
Wiki, but still a lot of stuff are missing. For sure I'll put an
"Introduction to Redis sorted sets" tutorial before 1.1.

Can I add you to project with privileges to modify the wiki?

Reply all
Reply to author
Forward
0 new messages