21:43 #tor-dev: < rndm> karsten, looks like this now if it gets the maximum number of results http://globe.rndm.de/#/search/query=
You're not online now, so replying via email:
Looks really good!
Minor tweaks to the phrasing:
"To avoid too many requests," -> the better motivation is that a) we don't want to overload the poor Onionoo server and b) reduce delays and bandwidth requirements for the client. I think users will understand b) better and not care much about a). How about "To reduce waiting time and limit bandwidth usage," ?
"try to use a search word" -> this message also shows up if the user tried a search term that is too general. How about "try to refine your search" ?
Thanks! Nice work!
Best, Karsten
On 12.08.2013 08:23, Karsten Loesing wrote:
21:43 #tor-dev: < rndm> karsten, looks like this now if it gets the maximum number of results http://globe.rndm.de/#/search/query=
You're not online now, so replying via email:
Looks really good!
Minor tweaks to the phrasing:
"To avoid too many requests," -> the better motivation is that a) we don't want to overload the poor Onionoo server and b) reduce delays and bandwidth requirements for the client. I think users will understand b) better and not care much about a). How about "To reduce waiting time and limit bandwidth usage," ?
"try to use a search word" -> this message also shows up if the user tried a search term that is too general. How about "try to refine your search" ?
Thanks! Nice work!
Best, Karsten
Thanks for your correction, I'm going to add it soon.
I've seen that you've included the field parameter to limit the fields that onionoo returns. Do you think it would be better to use the field parameter and show a limited amount of data or try to get everything and only display the fields that have a value?
Btw I had an idea to create a small js snippet that allows users to show data of an relay or bridge. It would use the onionoo api to send a request with a given fingerprint and renders the result in a small piece of html. This way someone won't need to link to a specified globe/atlas page and can directly show visitors information about an relay/bridge. I don't know if it would be useful for anyone. What's your opinion on that?
Cheers, Christian
On 8/12/13 10:56 PM, Christian wrote:
I've seen that you've included the field parameter to limit the fields that onionoo returns. Do you think it would be better to use the field parameter and show a limited amount of data or try to get everything and only display the fields that have a value?
You mean for details pages? I'd say display everything that has a value. Unless I didn't understand your question.
But here's something else that just came to mind that you could do with the fields parameter: in the search part, instead of sending a request for the summary document, just request the details documents, but only ask for the fields you're planning to display in the table. Once the user wants to see the details page, you'll have to fetch the full details for that relay or bridge. But you should be able to save quite a few requests and make the client application even more responsive.
Btw I had an idea to create a small js snippet that allows users to show data of an relay or bridge. It would use the onionoo api to send a request with a given fingerprint and renders the result in a small piece of html. This way someone won't need to link to a specified globe/atlas page and can directly show visitors information about an relay/bridge. I don't know if it would be useful for anyone. What's your opinion on that?
Sounds very useful and related to this Onionoo client idea stated on Onionoo's project page:
"Social network site plugin: Add a plugin to the social network site of your choice to show your friends what Tor relays and bridges you're running and how that helps users around the world."
(from https://www.torproject.org/projects/onionoo.html.en)
I believe that a student of Steven Murdoch is working on something like this for a school/university project. I hear they might be looking for testers really soon. Maybe you can help out there, or at least learn what design choices they made and either copy them or do things differently. I'm cc'ing Steven, so you can get in touch with him and his student more easily.
All the best, Karsten
On 13.08.2013 09:20, Karsten Loesing wrote:
On 8/12/13 10:56 PM, Christian wrote:
I've seen that you've included the field parameter to limit the fields that onionoo returns. Do you think it would be better to use the field parameter and show a limited amount of data or try to get everything and only display the fields that have a value?
You mean for details pages? I'd say display everything that has a value. Unless I didn't understand your question.
But here's something else that just came to mind that you could do with the fields parameter: in the search part, instead of sending a request for the summary document, just request the details documents, but only ask for the fields you're planning to display in the table. Once the user wants to see the details page, you'll have to fetch the full details for that relay or bridge. But you should be able to save quite a few requests and make the client application even more responsive.
That's a gread idea. I just implemented it in a new branch and it works so far. Without any futher testing it looks like the size for a single detail request went from ~1.9KB to ~1KB.
Btw I had an idea to create a small js snippet that allows users to show data of an relay or bridge. It would use the onionoo api to send a request with a given fingerprint and renders the result in a small piece of html. This way someone won't need to link to a specified globe/atlas page and can directly show visitors information about an relay/bridge. I don't know if it would be useful for anyone. What's your opinion on that?
Sounds very useful and related to this Onionoo client idea stated on Onionoo's project page:
"Social network site plugin: Add a plugin to the social network site of your choice to show your friends what Tor relays and bridges you're running and how that helps users around the world."
(from https://www.torproject.org/projects/onionoo.html.en)
I believe that a student of Steven Murdoch is working on something like this for a school/university project. I hear they might be looking for testers really soon. Maybe you can help out there, or at least learn what design choices they made and either copy them or do things differently. I'm cc'ing Steven, so you can get in touch with him and his student more easily.
All the best, Karsten
Ok thanks.
Cheers, Christian
On 8/13/13 10:43 PM, Christian wrote:
On 13.08.2013 09:20, Karsten Loesing wrote:
On 8/12/13 10:56 PM, Christian wrote:
I've seen that you've included the field parameter to limit the fields that onionoo returns. Do you think it would be better to use the field parameter and show a limited amount of data or try to get everything and only display the fields that have a value?
You mean for details pages? I'd say display everything that has a value. Unless I didn't understand your question.
But here's something else that just came to mind that you could do with the fields parameter: in the search part, instead of sending a request for the summary document, just request the details documents, but only ask for the fields you're planning to display in the table. Once the user wants to see the details page, you'll have to fetch the full details for that relay or bridge. But you should be able to save quite a few requests and make the client application even more responsive.
That's a gread idea. I just implemented it in a new branch and it works so far. Without any futher testing it looks like the size for a single detail request went from ~1.9KB to ~1KB.
Hmm, when you say "single detail request", I wonder if I explained my idea correctly. Let me try again, this time with an example:
Assume somebody searches for "gab". This currently generates the following requests to Onionoo:
[10:32:16.950] GET https://onionoo.torproject.org/summary?limit=50&search=gab [HTTP/1.1 304 Not Modified 141ms] [10:32:17.108] GET https://onionoo.torproject.org/details?lookup=A79E50FC2C7C8B19D44778C39BD3B5... [HTTP/1.1 304 Not Modified 140ms] [10:32:17.110] GET https://onionoo.torproject.org/details?lookup=B94F71EA1A0D7E904200A20C9063B0... [HTTP/1.1 304 Not Modified 280ms] [10:32:17.111] GET https://onionoo.torproject.org/details?lookup=16EF359C2FBF50FC08CF9A95717BE3... [HTTP/1.1 304 Not Modified 417ms]
My idea was to turn these requests into a single request:
https://onionoo.torproject.org/details?limit=50&search=gab&fields=ni...
And once somebody wants to look at gabelmoo's details, just download the full details document, plus bandwidth and weights for the graphs:
[10:32:17.111] GET https://onionoo.torproject.org/details?lookup=16EF359C2FBF50FC08CF9A95717BE3... [HTTP/1.1 304 Not Modified 417ms] [10:36:44.356] GET https://onionoo.torproject.org/weights?lookup=16EF359C2FBF50FC08CF9A95717BE3... [HTTP/1.1 200 OK 686ms] [10:36:44.357] GET https://onionoo.torproject.org/bandwidth?lookup=16EF359C2FBF50FC08CF9A95717B... [HTTP/1.1 200 OK 442ms]
All the best, Karsten
On 14.08.2013 10:38, Karsten Loesing wrote:
On 8/13/13 10:43 PM, Christian wrote:
On 13.08.2013 09:20, Karsten Loesing wrote:
On 8/12/13 10:56 PM, Christian wrote:
I've seen that you've included the field parameter to limit the fields that onionoo returns. Do you think it would be better to use the field parameter and show a limited amount of data or try to get everything and only display the fields that have a value?
You mean for details pages? I'd say display everything that has a value. Unless I didn't understand your question.
But here's something else that just came to mind that you could do with the fields parameter: in the search part, instead of sending a request for the summary document, just request the details documents, but only ask for the fields you're planning to display in the table. Once the user wants to see the details page, you'll have to fetch the full details for that relay or bridge. But you should be able to save quite a few requests and make the client application even more responsive.
That's a gread idea. I just implemented it in a new branch and it works so far. Without any futher testing it looks like the size for a single detail request went from ~1.9KB to ~1KB.
Hmm, when you say "single detail request", I wonder if I explained my idea correctly. Let me try again, this time with an example:
Assume somebody searches for "gab". This currently generates the following requests to Onionoo:
[10:32:16.950] GET https://onionoo.torproject.org/summary?limit=50&search=gab [HTTP/1.1 304 Not Modified 141ms] [10:32:17.108] GET https://onionoo.torproject.org/details?lookup=A79E50FC2C7C8B19D44778C39BD3B5... [HTTP/1.1 304 Not Modified 140ms] [10:32:17.110] GET https://onionoo.torproject.org/details?lookup=B94F71EA1A0D7E904200A20C9063B0... [HTTP/1.1 304 Not Modified 280ms] [10:32:17.111] GET https://onionoo.torproject.org/details?lookup=16EF359C2FBF50FC08CF9A95717BE3... [HTTP/1.1 304 Not Modified 417ms]
My idea was to turn these requests into a single request:
https://onionoo.torproject.org/details?limit=50&search=gab&fields=ni...
And once somebody wants to look at gabelmoo's details, just download the full details document, plus bandwidth and weights for the graphs:
[10:32:17.111] GET https://onionoo.torproject.org/details?lookup=16EF359C2FBF50FC08CF9A95717BE3... [HTTP/1.1 304 Not Modified 417ms] [10:36:44.356] GET https://onionoo.torproject.org/weights?lookup=16EF359C2FBF50FC08CF9A95717BE3... [HTTP/1.1 200 OK 686ms] [10:36:44.357] GET https://onionoo.torproject.org/bandwidth?lookup=16EF359C2FBF50FC08CF9A95717B... [HTTP/1.1 200 OK 442ms]
Haha yeah i misread that, sorry. I implemented your idea and it's really fast now with only 1 search request.
Thanks, Christian
-
Christian -
Karsten Loesing