[tor-dev] Anyone wanting to write some Weather-tight code?

[Nufuk]

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
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev