-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I figured it might make sense to discuss this in a separate thread.
And just in case you were wondering, if you ever have a feature request for Onionoo, I'd be happy to discuss that. In contrast to some of its clients, Onionoo itself is actively maintained.
Actually I came to the conclusion that it would make sense to move the myfamily grouping to the backend since any other compass grouping is based on onionoo data and not on data "generated" by compass itself (grouping key).
The MyFamily grouping takes also a bit CPU time. So "computing" families once per generated details document make a lot more sense than recalculating them in every compass query again.
Since the MyFamily is subject to change [1] is also relevant here.
[1] https://lists.torproject.org/pipermail/tor-dev/2015-March/008516.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
another good reason to move it to the backend: Virgil (also using MyFamily data to group relays) and any other application using onionoo can also take advantage of that (no need to re-implement it n times).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Nusenu:
I figured it might make sense to discuss this in a separate thread.
And just in case you were wondering, if you ever have a feature request for Onionoo, I'd be happy to discuss that. In contrast to some of its clients, Onionoo itself is actively maintained.
Actually I came to the conclusion that it would make sense to move the myfamily grouping to the backend since any other compass grouping is based on onionoo data and not on data "generated" by compass itself (grouping key).
The MyFamily grouping takes also a bit CPU time. So "computing" families once per generated details document make a lot more sense than recalculating them in every compass query again.
Actually it is be a lot easier then I tough and does not require a backend change at all, so you can ignore this one.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 23/03/15 15:26, Nusenu wrote:
Nusenu:
I figured it might make sense to discuss this in a separate thread.
And just in case you were wondering, if you ever have a feature request for Onionoo, I'd be happy to discuss that. In contrast to some of its clients, Onionoo itself is actively maintained.
Actually I came to the conclusion that it would make sense to move the myfamily grouping to the backend since any other compass grouping is based on onionoo data and not on data "generated" by compass itself (grouping key).
The MyFamily grouping takes also a bit CPU time. So "computing" families once per generated details document make a lot more sense than recalculating them in every compass query again.
Actually it is be a lot easier then I tough and does not require a backend change at all, so you can ignore this one.
Okay, just in case you change your mind, let's talk more about integrating this into Onionoo. There's already the `family` parameter which I specifically added for Virgil's thing. Though for Compass (or its successor), you'd probably want a new field in details documents, not a parameter. Just let me know.
All the best, Karsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Karsten Loesing:
Okay, just in case you change your mind, let's talk more about integrating this into Onionoo. There's already the `family` parameter which I specifically added for Virgil's thing.
Yes I'm using the 'family' list as well now - perfectly fits my needs.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Nusenu:
Okay, just in case you change your mind, let's talk more about integrating this into Onionoo. There's already the `family` parameter which I specifically added for Virgil's thing.
Yes I'm using the 'family' list as well now - perfectly fits my needs.
After comparing results of different group by family approaches (expensive vs. simple and fast) I noticed the simple version does not come without a drawback (requiring perfect matches has its consequences), but I'll play around a bit more before coming to a final conclusion or before requesting any backend feature.