ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-02-22 10:20:59 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

clear now they are not necessarily consecutive

Browse Source
This commit is contained in:
Jean-Paul Calderone 2018-05-15 09:41:45 -04:00
parent 599bf074e3
commit b6572e2856
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/proposed/http-storage-node-protocol.rst
View File

@ -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. The mapping has share numbers as keys and bucket identifiers as values.
For example:: For example::
.. XXX Share numbers are logically integers and probably sequential starting from 0. .. XXX Share numbers are logically integers.
But JSON cannot encode them as integers if they are keys in a mapping. JSON cannot encode integer mapping keys.
Is this really a mapping or would an array (with share number implied by array index) work as well? So this is not valid JSON but you know what I mean.
{0: "abcd", 1: "efgh"} {0: "abcd", 1: "efgh"}
@ -145,9 +145,9 @@ The response body includes encoded information about the created buckets.
For example:: For example::
.. XXX Same deal about share numbers as integers/strings here. .. 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, ...], {"already_have": [1, ...],
"allocated": {"7": "bucket_id", ...}} "allocated": {7: "bucket_id", ...}}
.. [#] What are best practices regarding TLS version? .. [#] What are best practices regarding TLS version?
Would a policy of "use the newest version shared between the two endpoints" be better? Would a policy of "use the newest version shared between the two endpoints" be better?