Hi,
I made changes to the overall-design and added the files as an attachement to the site. I would like to implement the "daily" script and make a DB design diagramm. I would attach the DB design to the page when I finished it.
Could you please provide a quick brainstorm what the DB needs, so I won't forget anything.
regards
Norbert Kurz
Am 13.01.2014 17:25, schrieb Abhiram Chintangal:
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