Skip to content
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

Support RESP3 #50

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Open

Support RESP3 #50

wants to merge 14 commits into from

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Feb 6, 2019

This adds full support for RESP3 while keeping backwards compatibility. Most things should stay on par performance wise.

My intention here is to first fully support the spec and to improve the performance later on for the new data types. Especially as the logic would become increasingly difficult otherwise due to the new attribute type (data that should be ignored while delivering it to the user in an unspecified way).

I have no strong opinion about the way push data and attributes is implemented and I am happy to get some input about those.

@luin @Salakar PTAL

@Salakar Salakar self-assigned this Feb 8, 2019
@BridgeAR
Copy link
Member Author

@Salakar you assigned this to yourself, do you still want to have a look at it?

@Salakar
Copy link
Member

Salakar commented Feb 20, 2019

@Salakar you assigned this to yourself, do you still want to have a look at it?

I did sorry, but my time has been 💩 if you'd like to continue without my review that's fine ofc 👍

@Salakar
Copy link
Member

Salakar commented Feb 5, 2020

Could we not keep the RESP 2 & 3 parsers separate files and export each for clients to use, that way logic for RESP2 doesn't need to interfere with RESP3 and each can be optimised for their specific protocol version.

My understanding from this was that to switch to RESP3 the client needs to send a HELLO command during connection handshake anyway whilst using RESP2 by default, meaning the client code will know based on the response which protocol to use - e.g. client starts on RESP2 then swaps it out for RESP3 if HELLO command says the protocol is supported?

This also has the added benefit of keeping RESP2 unchanged and stable whilst also future proofing the parser should any new protocol versions need adding in future.

@IAmEddieDean
Copy link

has anyone taken a look at this anytime recently? happy to help in any way I can, but don't wanna redo someone else's work or step on anyone's toes.

@Miantang
Copy link

has anyone taken a look at this anytime recently?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants