[tor-dev] Anyone wanting to write some Weather-tight code?
tor at nufuk.com
Sun Jan 12 12:44:44 UTC 2014
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.
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?
>>> 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.
>>> 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,
> tor-dev mailing list
> tor-dev at lists.torproject.org
More information about the tor-dev