redis-specifications
redis-specifications copied to clipboard
redis
A bin for Redis' specs
Currently RESP3 specification allows to encode the same data types in alternative ways because of their different semantic meaning. For example: - A map data can be encoded as: (1)...
It seems RESP v2 and RESP3 do not clearly distinguish between text strings (*strings* for short) and binary strings, clobs, blobs (*binary* for short). I might missing something, if so...
The spec states: > and the first element of the array is always a String item, representing the kind of push data the server is sending to the client I...
The blob error section says > It is exactly like the String type Maybe this should read the blob string type, for clarity? --- Blob strings can be parsed normally,...
For the Verbatim string ``` =15 txt:Some string ``` Should the client return `"Some String"`, or `"txt:Some string"`? I would suggest the former, and I would also suggest that the...
The redis [website](https://redis.io/docs/reference/protocol-spec/#simple-errors) states: > Note that the error prefix is a convention used by Redis rather than part of the RESP error type. But the RESP3 spec in this...
This pull request is another in the ongoing attempt to reserve base uri arguments and ensure that users can begin to have similar expectations as they move between redis clients.
Currently, error types (Simple error and Bulk error) return text strings as errors, however, the specification does not explicitly state that the string is a text string and in which...
[Original issue](https://github.com/antirez/RESP3/issues/28) -- Streamed types are modeled with an unknown length. However, the individual chunk lengths are known. Defining an EOF marker and stream-parsing the EOF marker introduces a certain...
