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? 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. :( What's the alternative? Use Globe's current codebase and turn it into something that runs in nodejs, which is contained in wheezy-backports? Thanks! All the best, Karsten -- 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