# RESP3 design and backward compatibility in Redis 6

DevFeed: [RESP3 design and backward compatibility in Redis 6](<https://devfeed.tech/articles/why-resp3-will-be-the-only-protocol-supported-by-redis-6-20616.md>)

Original publisher: [Read original article](<http://antirez.com/news/125>)

Published: 2018-11-09T15:31:10Z

Content type: opinion

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [client library](<https://devfeed.tech/topics/client-library.md>)

Tags: [client-library](<https://devfeed.tech/tags/client-library.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [redis](<https://devfeed.tech/tags/redis.md>)

## AI overview

The author discusses implementing RESP3, a more semantic client-server protocol planned for Redis 6. An edit says that enabling RESP3 per connection could address backward-compatibility concerns and changes the author's view of the original proposal.

## Source excerpt

[EDIT! I'm reconsidering all this because Marc Gravell from Stack Overflow suggested that we could just switch protocol for backward compatibility per-connection, sending a command to enable RESP3. That means no longer need for a global configuration that switches the behavior of the server. Put in that way it is a lot more acceptable for me, and I'm reconsidering the essence of the blog post] A few weeks after the release of Redis 5, I'm here starting to implement RESP3, and after a few days of work it feels very well to see this finally happening. RESP3 is the new client-server protocol that Redis will use starting from Redis 6. The specification at https://github.com/antirez/resp3 should explain in clear terms how this evolution of our old protocol, RESP2, should improve the Redis ecosystem. But let's say that the most important thing is that RESP3 is more "semantic" than RESP2. For instance it has the concept of maps, sets (unordered lists of elements), attributes of the returned data, that may augment the reply with auxiliary information, and so forth. The final goal is to make new Redis clients have less work to do for us, that is, just deciding a set of fixed rules in order to convert every reply type from RESP3 to a given appropriate type of the client library programming language. In the future of Redis I see clients that are smarter under the hood, trying to do their best in order to handle connections, pipelining, and state, and apparently a lot more simpler in the user-facing side, to the point that the ideal Redis client is like: result = redis.call("GET",keyname); Of course on top of that you can build more advanced abstractions, but the bottom layer should look like that, and the returned reply should not require any filtering that is ad-hoc for specific commands: RESP3 return type should contain enough information to return an appropriate data type. So HGETALL will return a RESP3 "map", while LRANGE will return an "array", and EXISTS will return a RE