Hi Norman,
On 8/3/12 8:22 PM, Norman Danner wrote:
A few questions on the Onionoo protocol specification:
If multiple parameters are specified in the GET request, does that imply a logical and or a logical or (or something else)? E.g., suppose the GET request has type=relay and lookup=FFFF... . To me it seems like that should return the relay with fingerprint FFFF..., if there is such a relay. But it could also mean return all relays as well as the router with fingerprint FFFF... .
It's a logical and. (Will clarify that in the spec.)
The search parameter is described as "Return only relays with the parameter value matching the beginning of a nickname, (possibly $-prefixed) fingerprint, or IP address..." Do you mean that the parameter value matches the beginning of a nickname, the beginning of a (possibly $-prefixed) fingerprint, or is one of the relay IP addresses?
It's the beginning of any of the three. (Will clarify that in the spec, too.)
For ordering, what do you mean by "possible fields for ordering are: consensus_weight." This is really two questions. How is the consensus_weight ordering defined when producing a summary document (which doesn't include a consensus weight field)? Can clients not request that summary documents be ordered by any of the 'n', 'f', 'a', or 'r' fields?
The ordering is, like all parameters, defined independent of the returned document type. (Will try to clarify that in the spec, too.)
At the moment, clients can only request ordering by consensus weight, because that's the first and only thing we needed so far. In the future, clients should be able to order by nickname, fingerprint, address and maybe even the running bit. Related to the first answer, clients wouldn't request ordering by the "n" field, but by the "nickname", regardless of the document they request. Details documents probably give a better idea of which fields could be used for ordering.
Hope that makes sense.
Best, Karsten