Switch to ArdorForum

here is the last dapp test, a tiny (2500 bytes), generic nxt account viewer plus a bter quote fetcher.
not pretty but this isn't important to test external api calls and some other features.

i have added two additional tabs to the helix loader, REPO (source load) and IMAGE (storage endpoint).
instead loading the code from the blockchain as before, the code is now hosted on the finhive server
including a fallback location, defined by: http://finhive.com/download/rep.json

the file looks like this:

      repo:  "http://finhive.com/download/rep.json"
      app:   "http://finhive.com/download/3.hlx"
      upd:   "http://finhive.com/download/update.json"
      nxt:   "http://23.88.59.40:7876/nxt?requestType=getAccount&account="
      bter:  "http://data.bter.com/api/1/tickers_error"
      limg:  "http://i.imgur.com/7m0Y3PN.jpg"
      simg:  "http://finhive.com/download/yadda.png"
      mod1:  "http://finhive.com/download/4.hlx"   
      appfb: ""
      modfb: "https://gist.githubusercontent.com/anonymous/6d91bd4259af71c1f7c9/raw/0d31b781096c342718acc2487d55097afb805ed1/gistfile1.txt"
      acc:   "9529893552967478846"

besides the api call for nxt and bter, it reference also to a the app/support modul source (app/mod1) and to a source image (limg).
if invoked, helix reads this file and loading, decrypt and decompress all resources into memory and starts the app in a second.



if you take a closer look to the bter resource, you can see, that the api link is wrong. helix detect this and is looking for
an availabe update or repair option provided by the upd resource link. the file: http://finhive.com/download/update.json
contains a workable bter element, which replaces the old one and invokes the fetch again. the CHECK button is used to check
the resource integrity and the update to invoke this procedure (the real Helix will do this automatically later).
since the code is now fine, helix can modify/serialize its own code to store the fixed version to a storage endpoint, which could
be the blockchain, another server or even a direct cast to another helix client via simple tcp/udp. for fun we are choosing
an image (steganography) as a datacontainer for the code, by invoking store. helix fetches the image from it's source (daedalus)
and displays it for adding the code. since the steganography modul is needed to do so, the mod1 resource is loaded as usual
to provide this functionality (btw, all those loadings are super fast due to tiny code size, feels like a local app without
bothering lagging)


 
after embedding the code, a new image is generated and stored on the server. if you take a closer look to the image, you can see
the pixel encoding, looks similar to compression artifacts known from unclean jpegs.

here is the image with the embedded app code (2500 bytes) :
http://finhive.com/download/yadda.png

here a zoom to show the pixel encoding in higher resolution:
http://finhive.com/download/yadda_s.png

and here on a blank image:
http://finhive.com/download/white_enc.png

we can now test to execute the embedded code, simple by loading the image direct into memory from the server
and decoding it. looks good, we can see a second instance and changing the account.
a tiny nxt account/quote viewer living within a skynet image ;-)



finaly:
this isn't a features only availabe by helix. nearly every interpreter based code can be used this way,
although some languages are better suited for this like lisp/scheme/r2/smalltalk etc
(iirc even ethereum is using lisp for contracts) providing out of the box selfreflecting, serialization
and more well suited features but even C could be used this way (yes, i know, security) e.g. by using lua
and compiling TCC [2] into a shared lib, able to compile/run C sourcecode on the fly the same way as above.

[1] http://en.wikipedia.org/wiki/Steganography
[2] https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.c