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

[Christian <me@xxxxxxx>]

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.

> 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.

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
or something alike).

Cheers,
Christian

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk