Re: [tor-dev] Stem Proc Integration Tests

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev