On Wednesday, January 8, 2014 at 1:49 PM, Christian wrote: > On 08.01.2014 08:52, Karsten Loesing wrote: > > On 1/7/14 2:29 PM, Christian wrote: > > > On 07.01.2014 13:44, Karsten Loesing wrote: > > > > On 1/7/14 1:32 PM, Christian wrote: > > > > > Hi, > > > > > sorry for the late answer. > > > > > > > > > > On 30.12.2013 16:53, Arlo Breault wrote: > > > > > > I wrote a little proof of concept rendering globe server-side with > > > > > > phantom.js > > > > > > https://github.com/makepanic/globe/pull/42 > > > > > > > > > > > > > > > > > > On Sunday, December 29, 2013 at 1:42 AM, Karsten Loesing wrote: > > > > > > > > > > I like this idea but don't know what the better approach would be. > > > > > > > > > > Is the plan to avoid a JavaScript client side implementation as a > > > > > relay/bridge search service or just provide a fallback for users that > > > > > have JavaScript disabled? > > > > > > > > > > > > > > > > > I guess whatever works in browsers that don't have JavaScript is fine. > > > > > > > > I'm unclear what the difference between your two options is. Does the > > > > second option check whether the user has JavaScript enabled or disabled > > > > and return a different website, and does the first always return the > > > > website that requires no JavaScript? > > > > > > > > > > > > > The implementation by Arlo uses phantomjs (http://phantomjs.org/) to > > > render the current globe url in a headless browser and puts it inside > > > the <noscript> element. > > > > > > If the user has JavaScript enabled the noscript element is hidden and > > > the browser uses the clientside JavaScript for routing, templating and > > > onionoo requests. > > > > > > If the user has JavaScript disabled, the clientside JavaScript code will > > > not execute and the content of <noscript> is visible. > > > > > > Arlo changed the routing behavior of Emberjs to use the history-api > > > which allows routing without the hashchange event (/#/top10 becomes > > > /top10 in browsers that support it http://caniuse.com/history ). > > > > > > This means that if the user without JavaScript wants to see another view > > > he has to start a new requests and phantomjs renders the new page and > > > the server returns the html. > > > The user with JavaScript enabled uses the clientside templates and can > > > continue without a request. > > > > > > In the end they both of them see the same output but the user without > > > JavaScript has to start a new requests if he wants to see another view. > > > > > > Please correct me if I'm wrong Arlo. > > > > > > > > > > > What's the easiest for you to maintain? > > > > > > I'm not sure but the phantomjs implementation requires less amount of > > > work to provide a JavaScript free way to search bridges and relays. We > > > only have to make some minor changes (expand the advances search by > > > default, fix fontawesome icons, ...). > > > Another advantage is that we can continue to use the current test/build > > > setup. > > > > > > > > > It seems that most things in Globe could work just fine without > > client-side JavaScript. The only problem might be bandwidth and weights > > graphs. How does Arlo's version display graphs? > > > > > As far as i know it doesn't display the graphs right now. Right, they’re currently rendered client-side to a canvas. Switching to svgs, as you mention below, would be necessary. > > > However, I just looked at Debian's package search page, and there's no > > phantomjs in wheezy nor wheezy-backports. That means we probably can't > > run it on a Tor machine. :( > > > > > Ok. Theoretically we could download the binary ( > http://phantomjs.org/download.html ) or build it ourself ( > http://phantomjs.org/build.html ). > > > What's the alternative? Use Globe's current codebase and turn it into > > something that runs in nodejs, which is contained in wheezy-backports? > > > > > That's what I'm currently working on. As of now, only bridge details and > graphs aren't completly ported. > >
Sounds like you’re most of the way there. I only suggested the phantomjs approach as a means to avoid a rewrite, but since you’ve pretty much gone and done it, we’re probably better off focussing on that. Let me know if there’s anything I can help with. Arlo > > If you think if it's better to use Arlos approach I can try to change > the current globe to make it more useable via phantomjs. > > Btw because we can't provide interactive graphs without JavaScript I'm > building an API that uses d3js (like atlas and earlier versions of > globe), renders the graphs serverside as SVG and returns them. > This way users can link and embed SVGs for specific fingerprints using a > simple url ( like globe.torproject.org/relay/bandwidth/:fingerprint.svg > (http://globe.torproject.org/relay/bandwidth/:fingerprint.svg) > or something alike). > > Cheers, > Christian > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > (mailto:tor-talk@lists.torproject.org) > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
