Realbasic on the web without plugins

[Pete]

Thanks for such a clear explanation of what is involved, Andre!
Pete
Molly's Revenge <http://www.mollysrevenge.com>




On Fri, Sep 23, 2011 at 12:13 PM, Andre Garzia <andre at andregarzia.com>wrote:

> 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...
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>