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