Hi, to make something this morning I made a fast and for sure not 100% correct design. But it describes roughly what I understood, the program should do and how. I made it with "Dia" open source OmniGraffle alternative. The link is on the wiki page and I hope we can use this as a first base to distribute the work packages and to discuss open topics. How to add properly files to the wiki? But the best is if you take a quick look.
Kind regards Norbert Am 12.01.2014 11:19, schrieb Karsten Loesing: > On 1/10/14 3:42 PM, Abhiram Chintangal wrote: >> On 01/09/14 22:07, Damian Johnson wrote: >>>> Hello Karsten, >>>> >>>> It looks like a nice little project to work on. I reguarly check my >>>> relay-status via Atlas, at the moment using the Onionoo service makes sense >>>> to me too. >>>> >>>> For now the onionoo-glue-code, seems like a good place to start. Do you >>>> have any other suggestions or ideas? >>>> >>>> thanks! >>> Hi Abhiram, glad you want to tackle this! I'm not sure if it makes >>> sense with the plan to rewrite Weather but six months back I submitted >>> a patch to swap the present Weather from TorCtl to Stem... >>> >>> https://trac.torproject.org/8264 >> Sounds great, I took a cursory look at the Django application in the >> repo, I should be able to reuse many modules from there. > Great! > >>> Testing and merging that might be a fine way of getting acquainted to >>> the present codebase and functionality. >> If I understood everything so far, I should look at ways to use >> Onionoo's restful service instead of the current approach which >> uses stem to grab hourly consensus updates of via the tor-network. > At least that's my suggestion, and I think it'll save us a lot of work > in the long run. When I designed Onionoo, I had Weather in mind as > possible client application. I think that Weather shouldn't have to > implement its own Tor network status database. That's something that > Onionoo already does, and it was painful enough to write. No reason to > maintain quite similar code in Weather. > > Obviously, there are also reasons against using Onionoo for the Weather > rewrite. For example, fixing current Weather *might* take less effort > than replacing its status database with an Onionoo client. And the new > Weather will depend on the Onionoo service, rather than on a larger set > of Tor directory authorities. > > Please don't hesitate to add your own pros and cons to this list. > > All the best, > Karsten > > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
