Consider letting user requests configure more
justindotpub opened this issue · 1 comments
There are sections of the spec that recommend a path but say you might want a different choice if you know better. For example...
Absent any other information, preorder traversal is RECOMMENDED. However, an implementation MAY choose another strategy, for instance if it knows that certain blocks will be preferred first.
All other factors being equal, breadth-first traversal is RECOMMENDED. Since the Provider is not expected to use the data immediately, it exposes the largest number of roots, and thus grants the highest chance of discovering shared subgraphs. An implementation MAY choose a different traversal strategy, for example if it knows more about the use.
For each round, the Requestor OPTIONALLY creates a Bloom filter with all leaf and interior CIDs for the nodes suspected to be shared with the structure that it is pulling. It sends this Bloom and the top CIDs to the Provider.
There may be others.
Some of these are described as implementation decisions, and I was assuming we'd just go with the recommended path. But it got me wondering if we should expose any of these decisions to the user request, similar to how they can pass a diff param to give hints on overlapping DAGs.
It sounds like we should probably include these as options, but this shouldn't be high priority.