On Sun, Jan 12, 2014 at 9:01 PM, Karsten Loesing karsten@torproject.org wrote:
On 1/12/14 1:44 PM, Nufuk wrote:
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.
Cool! I added some feedback on the page. Thanks!
How to add properly files to the wiki?
You should be able to attach files to wiki pages using the buttons at the bottom of the page. Let me know if that doesn't work for you (because of permissions or something).
All the best, Karsten
But the best is if you take a quick look.
Kind regards
Norbert
The diagram was helpful, Norbert. I have aslo added a few questions in the projects wiki page can both of you take a look.
Thanks!
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...
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 tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev