[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4439 [Metrics Utilities]: Develop a Java/Python API that wraps relay descriptor sources and provides unified access to them
#4439: Develop a Java/Python API that wraps relay descriptor sources and provides
unified access to them
-------------------------------+--------------------------------------------
Reporter: karsten | Owner: karsten
Type: task | Status: new
Priority: normal | Milestone:
Component: Metrics Utilities | Version:
Keywords: | Parent:
Points: | Actualpoints:
-------------------------------+--------------------------------------------
Comment(by karsten):
I finished an initial, non-functional version of the Java API this
weekend. I'd love to hear your thoughts on the design, atagar.
From the README:
{{{
DescripTor is a Java API that makes various Tor descriptor types available
for statistical analysis and for building services and applications.
The descriptor types supported by DescripTor include relay and bridge
descriptors which are part of Tor's directory protocol as well as Torperf
data files, GetTor statistics files, and TorDNSEL's exit lists. Access to
these descriptors is unified to facilitate access to publicly available
data about the Tor network.
This API is designed for Java programs that process Tor descriptors in
batches. A Java program using this API first sets up a descriptor source
by defining where to find descriptors and which descriptors it considers
relevant. The descriptor source then makes the descriptors available in a
descriptor store. The program can then query the descriptor store for the
contained descriptors. Changes to the descriptor sources after
descriptors are made available in the descriptor store will not be
noticed. This simple programming model was designed for periodically
running, batch-processing applications and not for continuously running
applications that rely on learning about changes to an underlying
descriptor source.
}}}
I could imagine that a good order to read the API is to start with the
example applications in `org.torproject.descriptor.example` and looking at
the relevant interfaces in `org.torproject.descriptor` whenever they're
referenced from the examples.
I'm attaching the code tarball to this ticket. Once there's a Git
repository, I'll move the code there. But what's a good name for this API
and the repository? I came up with "DescripTor," but maybe there's
something better? (I fear the English language may run out of words
ending in -tor...)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4439#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs