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