-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: RESP3 protocol support #156
Comments
@matobet would you care enough to work on it? ;) |
I suppose with the proper guidance I could give it a shot 😅 |
Sure, feel free to ask for help or a review, happy to assist! |
Hi @matobet, have you got any chance to work on this? |
@aravindgopall unfortunately no :-( |
I wrote a RESP3 parser here: https://github.com/414owen/resp RESP3 adds quite a lot of new syntactic forms, but it's still possible to parse it without backtracking. It should be complete, but tomorrow I'll double-check the spec, write a few more property tests, and upload it to hackage. |
I have a branch of hedis that uses the RESP3 protocol here. It passes all the tests, apart from one of the protocol pipelining ones. I'm not yet convinced that it's possible to do automatic pipelining with a pub/sub connection, but I need to think about it a bit more. The changeset is here. If anyone can figure out an easy way to do it, let me know. At the moment I'm considering splitting the connection into pipelined, and not pipelined (for pub/sub use). |
Yeah the pub/sub listener needs to inspect messages constantly, to know if they're a push message. This means we don't get pipelining. One way around that is to have a connection type specifically for pub.sub with commands. This would amount to one pipelined connection, and one not. It could be fairly transparent to the user, which is nice. I think that splitting the connection up (again, there's already the clustered one), really necessitates fixing this issue and parameterizing operations over the connection types they can run on. |
Are there any plans to support the new RESP3 protocol introduced in Redis 6?
Supporting it (along with its PUSH messages) would be helpful in supporting the Server-assisted client side caching in the future.
The text was updated successfully, but these errors were encountered: