[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 atagar):

 > My plan was to start without parsing descriptors at all and simply hand
 out raw descriptor strings.

 Agreed that is a good approach. I was gonna start in the opposite order
 because I needed parsing code for the control port content, but they're
 both independent chunks.

 > When you say you want to hack on this as part of stem, does that mean
 that stem will be able to handle non-Tor-control-port data sources?

 Yes. The plans for stem already go beyond just talking with the control
 port to include things like torrc templating and system utils for querying
 the tor process' pid, cwd, etc (actually I'm kinda cheating since I'd
 already written most of this for arm).

 > How do we proceed?

 Like I said I'll be busy with the basic functionality of stem for the next
 couple months. After that I'll be doing the parsing bits, then would be
 interested in tackling the alternate data sources. If you'd like to do
 that beforehand in java then that would certainly be a help (especially
 for pulling directly from directory authorities and mirrors) since then I
 could simply translate your implementation.

 > Should we start with writing a design document describing the scope of
 the new API?

 I'd rather see this grow organically, then use it for some of our own
 projects to mature the API before declaring it ready for external use. We
 can start with a design document if you'd like, but it's not necessary in
 my opinion.

 > How about we start this in a task-4439 directory in the metrics-tasks
 Git repository?

 You mean for the java implementation? I suppose it's fine for the java
 part of this library to live in metrics and the python implementation to
 be in stem.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4439#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online