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

[Karsten Loesing]

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