[tor-bugs] #4439 [Metrics Utilities]: Develop a Java/Python API that wraps relay descriptor sources and provides unified access to them

[Tor Bug Tracker & Wiki]

#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