bumping Redis-Clients-Dev list

[Ted Nyman]

Hey guys,

I wanted to send out a short email to this Redis-Clients-Dev list to
(hopefully) start some more discussion about Redis client development.
Over the following months, Redis will hopefully have server-side
clustering, among other new features -- and so client developers will
have a bunch of decisions to make. I think there are a few major
immediate and longer-term issues we should all think about. Some of
these have been discussed before.

1) What will the role of client libraries be w.r.t.
sharding/hashing/clustering once clustering is part of Redis itself?
2) Agreeing on standard algorithms for certain client-side operations
3) Formalizing a spec on 'what constitutes a Redis library'
4) The question of adding primitive types to Redis itself (Andy
McCurdy has mentioned this on a few occasions) and how this will tie
into the client libraries.
5) The possibility of adding a standardized JSON return for values

There are many more issues, of course -- in any case, I'd really love
to see more traffic on this list :)

Best,
Ted

[Jeremy Zawodny]

Are we concerned with consistency among libraries in the same language, such as having multiple Ruby or Java client libraries that can be used interchangeably in their respective languages?  Or is this about cross-language client compatibility?

As luck would have it, I just started poking at using the multi-bulk branch of the perl-Redis client with the 2.0.0 release candidate today.

Jeremy

[Daniele Alessandri]

On Fri, Jul 2, 2010 at 22:38, Ted Nyman <tnm...@gmail.com> wrote:

> 1) What will the role of client libraries be w.r.t.
> sharding/hashing/clustering once clustering is part of Redis itself?

Support for sharding at the client level will probably be less
important once server-side clustering will be available, but I think
that having it available on the client would still be handy. For
example I think that for most caching scenarios, client-side sharding
is more than enough.

> 2) Agreeing on standard algorithms for certain client-side operations

The algorithm used for client-side sharding is one of those for sure.
Other operations?

> 3) Formalizing a spec on 'what constitutes a Redis library'

One question that really bugs me is: should client libraries expose
commands using methods that map to the same names of the commands
themselves, as defined in Redis (e.g. mset, lpush, hset), or is it
acceptable that some of them define their own and more descriptive
names for their methods (e.g. multipleSet, pushHead, hashSet)?

Client libraries are abstractions so the latter makes sense after all,
but if we think of the Redis command set as a DSL to perform certain
operations on the server then I think that the former makes plenty of
sense, too. In fact, it is even more convenient to use the same names
for libraries methods: easier consultation of the command reference on
the Redis website and almost-no-brainer switch among different client
libs / languages.

I also think that this argument is valid only for "low-level" client
libraries or their actual core (if exposed to end-developers), not for
further abstractions built upon them (e.g. redis-objects or Rediska).

> 4) The question of adding primitive types to Redis itself (Andy
> McCurdy has mentioned this on a few occasions) and how this will tie
> into the client libraries.

Is it related to what Salvatore has mentioned in the latest SF meetup
while speaking about eventual protocol changes in future versions of
Redis? (reference: http://www.ustream.tv/recorded/7855635 starting
from 2h07m26s)?

> 5) The possibility of adding a standardized JSON return for values

IMHO this is out of the realm of what a client library should be able
to comply with to be considered a good one (I'm always thinking of
low-level libs).

> There are many more issues, of course -- in any case, I'd really love
> to see more traffic on this list :)

Indeed!

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