[tor-talk] Shutting down the relay-search service by the end of the year

Wed Jan 8 21:10:42 UTC 2014

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 at lists.torproject.org (mailto:tor-talk at lists.torproject.org)
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>  
>  