From b6572e2856009644bcb680c5df28e44f7f8d2552 Mon Sep 17 00:00:00 2001 From: Jean-Paul Calderone Date: Tue, 15 May 2018 09:41:45 -0400 Subject: [PATCH] clear now they are not necessarily consecutive --- docs/proposed/http-storage-node-protocol.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/proposed/http-storage-node-protocol.rst b/docs/proposed/http-storage-node-protocol.rst index e55156420..f991e5bd6 100644 --- a/docs/proposed/http-storage-node-protocol.rst +++ b/docs/proposed/http-storage-node-protocol.rst @@ -106,9 +106,9 @@ The mapping is returned as an encoded structured object The mapping has share numbers as keys and bucket identifiers as values. For example:: - .. XXX Share numbers are logically integers and probably sequential starting from 0. - But JSON cannot encode them as integers if they are keys in a mapping. - Is this really a mapping or would an array (with share number implied by array index) work as well? + .. XXX Share numbers are logically integers. + JSON cannot encode integer mapping keys. + So this is not valid JSON but you know what I mean. {0: "abcd", 1: "efgh"} @@ -145,9 +145,9 @@ The response body includes encoded information about the created buckets. For example:: .. XXX Same deal about share numbers as integers/strings here. - But here it's clear we can't just use an array as mentioned above. + {"already_have": [1, ...], - "allocated": {"7": "bucket_id", ...}} + "allocated": {7: "bucket_id", ...}} .. [#] What are best practices regarding TLS version? Would a policy of "use the newest version shared between the two endpoints" be better?