Realbasic on the web without plugins

[Andre Garzia]

On Fri, Sep 23, 2011 at 4:37 PM, Pete <pete at mollysrevenge.com> wrote:

> Thanks for such a clear explanation of what is involved, Andre!
>

Don't take it as the platonic truth... that was my approach only and what
I've seen thru the years. I bet there will be someone that will simply prove
me wrong.

Cheers and thanks for the kind words.
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
> >
> >
> _______________________________________________
> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.