Changes between Initial Version and Version 1 of Ticket #3777


Ignore:
Timestamp:
2021-08-23T14:22:42Z (3 years ago)
Author:
itamarst
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #3777

    • Property Owner set to exarkun
    • Property Type changed from defect to task
    • Property Milestone changed from undecided to HTTP Storage Protocol

  • Ticket #3777 – Description

    initial v1  
    1717
    1818Third, as part of documenting, it's worth thinking about the pattern in context of HTTP server implementations. HTTP server frameworks often don't preserve order _between_ parameters, only preserving order for multiple values of a single parameter. So e.g. `?share=1&share=2&offset=0&offset=100` will look the same as `?share=1&offset=0&share=2&offset=100` if you're using Twisted Web (or Flask), because you get back a mapping of argument key to list of values.
     19
     20Fourth, can I request multiple chunks from same share?
     21
     22Fifth, taking a step back and looking at the big picture, I am not certain that supporting reading from multiple shares (or more broadly, reading multiple chunks) in a single query is actually useful.
     23
     241. It's not clear to me it simplifies the client implementation.
     252. There are API design difficulties of receive arbitrarily sized multiple chunks in a single stream.
     263. Using single CBOR result streaming isn't really easy to support. Alternative is to concatenate multiple separately CBOR-encoded values (i.e. writing multiple results of `cbor2.dumpb` or whatever), which CBOR libraries can handle better.
     274. Given support for parallel requests, it doesn't improve latency (though it does have minor reduction in bandwidth usage).