On 6/28/12 11:37 PM, Damian Johnson wrote:
- integ tests are pretty short, and just run the parser against some
test data from the metrics archive and the cached consensus
Keep in mind that metrics tarballs can be huge. stem's tests probably shouldn't download one or more of these tarballs in an automatic integ test run.
PS. Karsten: Do we want to call this "NetworkStatusEntry" or something else? It seems like "ConsensusEntry" would be more intuitive, but maybe this would just spawn confusion.
A consensus is just one type of a network status. Other types are: - votes, - opinions (specified in proposal 147 and targeted for 0.2.4.x), - microdescriptor consensuses, - sanitized bridge network statuses, - v2 network statuses, and - v1 directories (which are quite different though).
So, for the Java metrics-lib I went with a single NetworkStatusEntry class for everything except v1 directory entries, but that won't scale forever. For example, "r" lines in consensuses are different from "r" lines in microdescriptor consensuses. The Java metrics-lib doesn't understand microdescriptor consensuses, because they don't contain anything new for statistical analysis, but I think stem will want to parse them. It probably makes sense to have an abstract NetworkStatusEntry class that does most of the parsing work but that can be specialized in its subclasses. Picking names like ConsensusEntry if the consensus class is called Consensus makes sense. If there's a similar concept to Java's inner classes in Python, maybe using something like Consensus.Entry might be a good choice, too, because this class will only be used as part of a Consensus.
Best, Karsten