Re: [tor-bugs] #22836 [Metrics/Metrics website]: Parse CollecTor's index.json and provide our own directory listing

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#22836: Parse CollecTor's index.json and provide our own directory listing
-------------------------------------+------------------------------
 Reporter:  karsten                  |          Owner:  karsten
     Type:  enhancement              |         Status:  needs_review
 Priority:  Medium                   |      Milestone:
Component:  Metrics/Metrics website  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:                           |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------------

Comment (by karsten):

 Heh, the good old index-handling classes discussion. We really disagree
 how to move forward there, don't we? :)

 So, I went back and forth about this, too.

 On the one hand the corresponding classes in metrics-lib are not part of
 the API yet, and they're not ready for that. (For example, I'd like to
 avoid that applications instantiate their own `*Node` classes. My
 preferred model would be that we provide some kind of `IndexGenerator`
 that takes one or more directories from the file system and generates a
 `*Node` structure and `index.json*` files from that. And an `IndexParser`
 would take an `index.json` file as input (or download it from a server)
 and provide a `*Node` structure as output. And all `*Node` classes would
 be interfaces, not classes, and they'd be located in packages that are
 part of the API.) But I can't really work on finalizing these classes
 enough to make them part of the API at this point. I'm trying to clean up
 a few things before the next Tor meeting, and making Tor Metrics the only
 user-facing website is one of them.

 On the other hand I agree that duplicating or triplicating code is bad. To
 be fair, we're talking about 20 lines of code here, so the risk for bugs
 is relatively low (though not zero).

 I can see two ways forward: a) We accept these 20 lines of duplicate code
 for now and plan to replace those classes with ones from metrics-lib once
 they're part of the API. b) We use types from metrics-lib despite them not
 being part of the API yet and put up a big warning sign that things might
 break if metrics-lib changes.

 What's your preference?

 Did you find anything else, or did you not look further after finding
 these internal `*Node` classes? :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22836#comment:5>
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