Realbasic on the web without plugins

Andre Garzia andre at andregarzia.com
Fri Sep 23 15:13:30 EDT 2011


Folks,

Speaking as someone who actually (tried to) build lots LC to Web tools I
must say that the challenge is not rendering the controls or converting the
language to javascript. That is not where the main issue lies. To convert LC
to the Web, you would need what I call an "LiveCode Kernel" implemented in
Javascript. This would be basically a reimplementation of the features we
have in the engine such as message path, all the commands, all the
functions, all the externals, all the controls, all of everything, in
javascript. someting like:

livecode.js

Now, a translation process would begin by exporting the stackfile format to
a json structure with all the properties and ownerships so that in the end
you have a complete translation of all the data that is in the stackfile to
a format that can be manipulated by javascript. With this json alone, you
would be able to render the user interface but the scripts would require
more work.

Multiple steps would be needed to convert the scripts of the stack. They
would be parsed into an AST of sorts, a graph or some storage medium that we
could use to keep our representation of the script. This AST-like thing
would then be exported to unoptimized javascript where all the LiveCode
commands and functions are just wrapped in javascript calls so a script
like:

  get totalTime
  add 1 to it
  put it into field "total"

would be converted to:

  lc.env.it = totalTime;
  lc.env.it += 1;
  lcSetObjectProperty(lcObjectReference("field","total"), "text", lc.env.it
);

You can see that there is no inteligence, it is a direct translation
changing all that would be LiveCode commands to javascript wrappers. a
global structure in the form of "lc.env.*" holds all the globals and special
variables. A helper function lcSetObjectProperty() is used to set any object
property using three parameters - the object reference, the property, the
value. Another helper function picks an object type and a name and returns
the reference that is used in the lcSetObjectProperty();

We're not translating LiveCode script to idiomatic Javascript, we're
wrapping LiveCode semantics in a JavaScript syntax. This would be very slow
but it would not be the hardest thing to build. Once you have a way to pick
an alternative stackfile representation like a JSON file and you have all
the engine features wrapped in your own javascript little kernel, you can
convert stacks to the web.

What many projects that boost their features as RAD tools for the web are
doing is something different. Instead of translating their stuff to
HTML+CSS+JS, what they do is wrap around the native program. They create a
virtual screen on the browser where the output that would usually go to X11
or something similar is sent to the browser in a CANVAS tag or SVG or JPG.
The raw mouse input such as coordinates and button status are constantly
sent back to the server along with the keyboard status. The server maintain
different client states for each connected user allowing the software to
mimic it being run as different instances. This can be accomplished with
closures and continuations. In this way, there is no conversion at all, you
have a wrapper that pipes output to the browser and pushes browser input
events to the server. All the logic and inteligence is on the server, there
is nothing business related on the browser.

This approach might sound more complicated but it is actually easier. Just
google for GTK on the Web and you will see a GTK adapter that just do that.
We can adopt that approach with LiveCode because we don't have multitasking
or closures or continuations so the user state management would be really
hard.

The previous approach of reimplementing the engine in javascript and passing
a stackfile representation around brings the logic and inteligence back to
the browser and the server has no dealing with it anymore. It is a harder
approach but it can be done. I started coding this during that Apple License
fiasco we had where they prohibited all the non-objc languages on the
appStore. I called the project RevImpossible and set a very slow pace. When
apple reverted their license, I saw no use in trying to reimplement
something that is so complex (it would take me years and a lot of smart
people with me). I shifted RevImpossible to another focus, it still converts
the visuals of stacks to the web but my focus is not the scripts anymore but
a quick way to prototype websites using RevIgniter.

My two cents
PS: REALStudio Web thing appears to use FastCGI. I demoed a Revolution
FastCGI library during RevConWest a long time ago...



More information about the use-livecode mailing list