[tor-relays] Metrics for assessing EFF's Tor relay challenge?

[Lukas Erlacher]

Hello Nikita, Karsten,

On 04/05/2014 05:03 PM, Nikita Borisov wrote:
> On Sat, Apr 5, 2014 at 3:58 PM, Karsten Loesing <karsten at torproject.org> wrote:
>> Installing packages using Python-specific package managers is going to
>> make our sysadmins sad, so we should have a very good reason for
>> wanting such a package.  In general, we don't need the latest and
>> greatest package.  Unless we do.
> What about virtualenv? Part of the premise behind it is that you can
> configure appropriate packages as a developer / operator without
> having to bother sysadmins and making them worried about system-wide
> effects.
>
> - Nikita

I was going to mention virtualenv as well, but I have to admit that I find it weird and scary, especially since I haven't found good documentation for it. If there is somebody who is familiar with virtualenv that would probably be the best solution.

On 04/05/2014 04:58 PM, Karsten Loesing wrote:
> My hope with challenger is that it's written quickly, working quietly
> for a year, and then disappearing without anybody noticing.  I'd
> rather not want to maintain yet another thing.  So, maybe Weather is a
> better candidate for using onion-py than challenger.

Yes, I understand.
> Yeah, I think we'll want to define a maximum lifetime of cache
> entries, or the poor cache will explode pretty soon.

What usage patterns do we have to expect? Do we want to hit onionoo to check if the cache is still valid for every request, or should we do "hard caching" for several minutes? The best UX solution would be to have a background task that keeps the cache current so user requests can be delivered without hitting onionoo at all.
In other words, unless we do something intelligent with the cache, the cache is not actually going to be very useful.

> Great, your help would be much appreciated!  Want to send me a pull
> request whenever you have something to merge?

Will do.

Cheers,
Luke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140405/7db712ea/attachment.sig>