[tor-bugs] #6682 [Compass]: merge atlas and compass?

[Tor Bug Tracker & Wiki]

#6682: merge atlas and compass?
-------------------------+--------------------------------------------------
 Reporter:  cypherpunks  |          Owner:     
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:     
Component:  Compass      |        Version:     
 Keywords:               |         Parent:     
   Points:               |   Actualpoints:     
-------------------------+--------------------------------------------------
Changes (by karsten):

 * cc: hellais, gsathya (added)
  * component:  - Select a component => Compass


Comment:

 I agree that Atlas and Compass have useful features that could be merged
 to avoid duplicating effort in the future.  The features you suggest
 (adding columns, making them configurable, and adding an advanced search)
 are all doable and just need (non-trivial amounts of) developer time.  I
 can see them to be added to either website, but I'd want to avoid them to
 be added to both, or we'll duplicate effort.  Let me explain why this
 decision for extending either Atlas or Compass is hard:

  - Atlas focuses on presenting information about a ''single relay'' to its
 users.  There is a search function in Atlas, but its main use is to look
 up a relay and present its details, including useful graphs.  People could
 as well bookmark details pages of their favorite relays and go from there.
 The design is that all the hard work is either done on the client using
 JavaScript or on the back-end called Onionoo which does all the searching
 work.  Atlas can only do some filtering and sorting of results it received
 from Onionoo, but Atlas shouldn't download the whole relay data (currently
 6.6M) for each request.  It would also be Onionoo that we'd have to extend
 to support advanced search and any other operations like sorting by the
 columns you mentioned.

  - Compass has its focus on the ''whole network''.  The motivation was to
 look at network diversity by grouping by country, AS, or family to see how
 much (exit) traffic a certain group of relays sees compared to other
 groups.  Another goal of Compass is to track progress of deploying fast
 exits for sponsor J, which also requires the full network view.  Compass
 is implemented as a server application and downloads the full relay data
 of 6.6M once per hour.

 As I see it, we have (at least) three choices here:

  - Keep Compass and Atlas separate by letting Compass do the
 searching/filtering/sorting and Atlas displaying single relay information.
 Configurable columns and advanced search would go into Compass then which
 would continue to link to Atlas' details pages.  We could even host the
 two applications on a single machine, so that they would appear as one
 service.
  - Extend Compass to do the advanced searching and all that, and have it
 also render the relay details page.  Then we wouldn't need Atlas anymore.
  - Extend Atlas to provide advanced searching/filtering/grouping options
 to users and implement them in Onionoo.  The we wouldn't need Compass
 anymore.

 In the end, the decision will be made by whoever is going to do the coding
 work.  But let's do some thinking before we decide for either design, or
 we might waste quite some developer time and maybe end up with a design we
 don't really like.

 Assigning this ticket to Compass, though Atlas would be a good fit, too.
 But it has to go somewhere, and "- Select a component" doesn't seem right.

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