[tor-bugs] #12944 [Onionoo]: onionoo protocol/client api and base implementaion

[Tor Bug Tracker & Wiki]

#12944: onionoo protocol/client api and base implementaion
-----------------------------+----------------------------
     Reporter:  iwakeh       |      Owner:  iwakeh
         Type:  enhancement  |     Status:  needs_revision
     Priority:  normal       |  Milestone:
    Component:  Onionoo      |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------------

Comment (by iwakeh):

 Thanks for carefully reading through all that code!

 Here some first answers and some questions (without patch).
 The other suggestions/questions I'll reply to later.

 >  - With the changed `build.xml` we now distinguish between server
 version and API/client version.  Wouldn't it be easier to just have a
 single version for both, where any API version x.y.* understands the
 protocol by server x.y.*?  Or am I oversimplifying things?
 I cannot recall why I introduced the longer version pattern.
 Your suggestion ought to be fine.


 >  - I assume the changes to `DetailsDocument` are mostly unrelated to
 this ticket and refer to the code comment `"TODO Maybe there's a more
 elegant way (more maintainable, more efficient, etc.) to implement
 this?"`?  I like the idea, but I have some concerns:
 >    - Does Gson still (de-)serialize details documents correctly with
 this new code?
 >    - Is there an easy way to preserve static type safety with the new
 approach?
 New ticket #13334

 >    - This change contracts the statement in package-info.java:
 > `This package does NOT implement the interfaces in {@link
 org.torproject.onionoo.protocol.docs}!`.
 Did you mean 'contradicts'?

 >  - Should we rename CharacterValidator to PrintableAsciiValidator to be
 extra precise?
 Good idea. I'll rename it.

 >  - Is the request "/SUMMARY" now valid?  If so, let's update the test
 rather than remove it.  Do we need to update any user documentation for
 that?  And should this change take place in its own commit?
 Update the test in the same commit seems better, otherwise there'd be a
 'commit' that fails the tests.
 No need to advertise this change, though. It'll be documented in the
 changed test.

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