JSON RPC question

[Arco]

Hi,

I'm working on a Windows client for Twister. Development is still in a really early phase, but I came across a problem which I would like to know more about.

I'm creating a new HTML front-end combined with Node-webkit. In all the Twister clients today, the Twister deamon serves the HTML of the applications, and JSON RPC calls get information from the deamon. I don't want this, since the application is useless if the deamon isn't ready to serve the HTML yet. But when serving the HTML from another server it can't call the deamon using JSON RPC, because of cross-domain scripting not being possible.

So my question is: does JSON RPC offer any benefits in comparison with calling twisterd.exe directly and capturing the output of the call? Or does JSON RPC do the exact same thing in the background? Which I assume it does, but I'd rather have it confirmed before I rewrite my current code base ;-)

Thank you for your time.

Arco

[Miguel Freitas]

Hi Arco,

On Fri, Apr 3, 2015 at 6:27 AM, Arco <arco...@gmail.com> wrote:

I'm working on a Windows client for Twister.

Great! :-)

 

So my question is: does JSON RPC offer any benefits in comparison with calling twisterd.exe directly and capturing the output of the call? Or does JSON RPC do the exact same thing in the background? Which I assume it does, but I'd rather have it confirmed before I rewrite my current code base ;-)

Actually when you execute some command using twisterd.exe it will be doing a JSON RPC behind the scenes to talk to the other twisterd instance (daemon).

So i'm not sure you would gain anything by adding this extra layer. Unless, of course, in languages/scripts where it is easier to execute a command than performing a JSON RPC directly.

regards,

Miguel

 

[Julian Steinwachs]

Hi Arco,

just want to let you know that i'm working on a related project. At https://github.com/Tschaul/LibTwister i'm building a Javascript library that implements the twister-api. I restrict it to the api calls that are available in public-server-mode (see [1] right column). The library is meant to serve as a basis for lightweight proxy-dependent client-side-encrypted html5-based apps that can either be hosted by a trusted domain, or from a native webview (like node-webkit). In your scenario, you have the server running locally, access to the full api and no need to do client-side encryption. So this is quite different. Nevertheless, you can look at my code and reuse some stuff. Right now i'm just tinkering, but i hope to get something polished within the next three weeks.

Greatings
Tschaul

[1] https://github.com/miguelfreitas/twister-core/blob/master/src/bitcoinrpc.cpp#L198

--

You received this message because you are subscribed to the Google Groups "twister-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to twister-dev...@googlegroups.com.

To post to this group, send email to twist...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arco Mul]

@Miguel: Thank you for your answer, it gave me the idea to switch to a non ajax based json rpc library (I used json-rpc2) and for that library I didn't get the cross browser scripting error.

@Tschaul: Great, I hope to upload my project on Github in the coming weeks. Let see if I can use your code by then or if we can combine what we both wrote ;-)

Arco

[W-M Wijnja]

This is great stuff!

What would be amazing, is to use this to make a web-application that lets webmasters run a Twister-'endpoint', i.e. that applications not directly connected to the Twister network can call to receive messages and user information about a certain search query. Just like e.g. twisterio.com, but returning simple JSON (or XML) data. The best thing would be to decentralize this a little, by having these systems could let each other know through the Twister network that they are live (and regularly send eachother a ping), and also send this list with known live twister-endpoints to the end user application, which might cache it to ensure that when one of the endpoints is down, the data can still be received from one of possibly many alternative sources.

I'm going to explore this possibility, as soon as I get the TwisterRPC connection to work...



Op donderdag 9 april 2015 10:54:44 UTC+2 schreef Arco Mul: