antirez / antirez/RESP3

Carification of attributes: arity, key uniquity, and permitted key types

Offen
#35 0 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Keine Sprachdaten
Sterne
230
Forks
41
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

Arity
---

For any (following) element, it seems clear that attributes can be omitted or present, but it isn't
explicit whether they can be repeated. For example, we know this is valid:

``` txt
|1
+ttl
:3600
:3
```

but is *this* valid

``` txt
|1
+ttl
:3600
|1
+priority
:7
:3
````

and if so (my personal preference would be "no, that isn't valid"), is it semantically identical to:

``` txt
|2
+ttl
:3600
+priority
:7
:3
````

or does it need to be possible to tell between the two scenarios?

---

Uniquity
---

How is the following to be interpreted?

``` txt
|2
+ttl
:3600
+ttl
:9001
:3
````

is this:

- illegal
- valid, last value wins (so: `ttl` = `9001`)
- valid, all values should be preserved (so: `ttl` = `[3600, 9001]` in some way)
- something else?

---

Permitted Key Types
---

(a lot of this may cross over into `map` more generally)

In a lot of platforms, it may be hard to reliably implement maps that can take arbitrary types as keys, as the equality semantics are very awkward. In reality, I can see a lot of clients would want to restrict handling to string-like types, as that is what most attributes are going to be keyed as. Now, sure, clients could choose to just treat all keys as blobs, but that has other problems.

As a pragmatic note, it may be sensible to consider whether it is actually required for attributes (and maps?) to allow keys that are, say, integers, doubles, big integers, in the case of attributes, it *might* even be prudent to limit it to simple strings, i.e. `+foo`

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.