hedis icon indicating copy to clipboard operation
hedis copied to clipboard

Feature request: RESP3 protocol support

Open matobet opened this issue 4 years ago • 8 comments

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.

matobet avatar Oct 28 '20 21:10 matobet

@matobet would you care enough to work on it? ;)

k-bx avatar Oct 29 '20 10:10 k-bx

I suppose with the proper guidance I could give it a shot 😅

matobet avatar Oct 29 '20 22:10 matobet

Sure, feel free to ask for help or a review, happy to assist!

k-bx avatar Oct 30 '20 09:10 k-bx

Hi @matobet, have you got any chance to work on this?

aravindgopall avatar Mar 16 '23 05:03 aravindgopall

@aravindgopall unfortunately no :-(

matobet avatar Mar 16 '23 11:03 matobet

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.

414owen avatar Jan 21 '24 21:01 414owen

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).

414owen avatar Jan 26 '24 20:01 414owen

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.

414owen avatar Jan 27 '24 09:01 414owen