I think most modern web apps you see run ui locally (client side) and then use an http-based server API to manage the 'cloud' side.
The advantage of this approach is that you end up with a good separation between client and server, meaning the client can be implemented on any platform (and using the same code - at least when using LiveCode). I wouldn't, however, rule out some means of defining server side behavior alongside the client side behavior and have LiveCode 'do the right thing'. However, that is perhaps a bit further down the line... We have a fair bit more work to do on the html5 port first! Mark. Sent from my iPhone > On 25 Feb 2016, at 19:02, Matt Maier <bluebac...@gmail.com> wrote: > > Thanks for that overview Richard, it helped me! > > Given option (b), will the entire livecode engine have to run client-side, > or will there be a way to let the engine run on a server? > > On Thu, Feb 25, 2016 at 10:23 AM, Richard Gaskin <ambassa...@fourthworld.com >> wrote: > >> Sannyasin Brahmanathaswami wrote: >> >>> So if we can run Landstat Satellites and entire Universities >>> (vienna), I humbly submit that it's time to realize "you did it" when >>> it comes to data management...and to put media delivery at the >>> forefront of the agenda not at the end of the agenda. >>> >>> The current generation is all about audio and video. "expect... all >>> at once...." Many of us have been asking for audio/video improvements >>> for well over the past ten years. So it's not as if we are coming out >>> of the blue.... >> >> We still don't have point-and-click data binding with a built-in MVC >> framework. >> >> But in all fairness those are things the community can do in script, >> whereas multimedia playback is very much an engine concern. >> >> I bring up MVC only to suggest that your priorities may not be mine, and >> mine may not be others'. >> >> As a Linux user I haven't been able to even just play a video at all in >> several years, while it's possible (with some codec/format limitations) on >> Windows and Mac users enjoy support for the latest OS media APIs. >> >> Since most of my current work is in data-intensive productivity apps this >> hasn't held me back; I share the story only to point out that priorities >> are as broad and varied as this community. >> >> >>> "difficult port" ?? there are any number of media player frameworks >>> built on JS... Perhaps I'm very dense, but JS is use for media >>> deliver *everywhere*... It's not about a player exactly.. but just to >>> be able to stream audio and video. >>> >>> So back to my question: is there another way to play media using >>> other means beside a player? >> >> Yes: let the browser do it. >> >> But to do that, you'd need to let the browser do it all. >> >> There are two very different worlds here: the desktop, run with OS APIs >> on binary structures and machine code; and the web, run with browser specs >> on textual data and JavaScript. >> >> These worlds do not collide. They are fundamentally different, designed >> for very different tasks. >> >> Before LC's HTML initiative, the two worlds were for the most part quite >> separate. No one expects to use XCode to write C++ apps in Cocoa and >> somehow run them in a browser. >> >> What LC is attempting here is a significant departure from a long history >> in which the two worlds, desktop and web, are very separate from one >> another. >> >> Given that the only execution engine commonly available in browsers is >> JavaScript, to migrate applications made in LiveCode into the confines of a >> web browser requires either of two approaches: >> >> a) Translate LC-native objects to browser-native HTML/CSS, and LC-native >> scripts to JavaScript. >> >> b) Translate the LC engine to JavaScript so LC-native objects and scripts >> need no translation. >> >> Either is a difficult task. >> >> Option a) makes it relatively easy to get appearances, but for >> functionality requires translating every line of LiveCode script into >> JavaScript. >> >> The appearance part isn't that hard: with a few hours it's possible to >> translate native LC objects into their HTML/CSS equivalents rather >> satisfyingly, with the result being lean browser-native layouts. >> >> But the functionality is not so easy. LiveCode and JavaScript are so very >> different in their syntax, logic, event and object models, that translation >> from one to the other is a mind-bendingly difficult task. >> >> Option b) is where we're headed instead, moving the entire LC engine into >> the browser by translating roughly three quarters of a million lines of C++ >> into JavaScript. >> >> This allows LiveCode scripts and objects to be handled more or less how >> they're handled in the desktop engine, without needing to translate >> LiveCode scripts. >> >> But given that the desktop and the web are such fundamentally different >> platforms, neither approach can be expected to be a seamless move. These >> are very different worlds; there is no magic pony. >> >> Option a) would allow us to export LC player controls as HTML5 player >> objects, but would require you to write any scripts you need in JavaScript. >> >> Option b) lets all your LC objects scripts go along for the ride since the >> LC engine they depend on is now a JavaScript object, but it means you don't >> have access to browser-native objects like HTML5 media support. >> >> If one were inclined to pursue option a), it could be possible to take the >> approach Toolbook and others have, in which functionality targeted for web >> deployment is limited to calls in LC libraries for which matching >> JavaScript libraries are provided. I first suggested this as a solution >> here in 2003, but no one was interested enough to help see it through. >> Could still be done, though, just not by myself. And while the >> functionality such libraries provide would be limited, the intersection of >> things we need to do on both desktop and web is somewhat limited by nature >> anyway, so for some apps it may not be a bad option. >> >> With option b), the one being pursued at the moment, there is the >> possibility that the LC engine code that handles media playback could be >> replaced post-translation with browser-native handling. Given the >> complexity of the output Emscripten produces this would not be trivial, and >> with the differences in the object model it may not be practical, but it >> might be possible. >> >> I don't know if any of this rambling post is helpful, but my aim here is >> just to point out the very difficult task being undertaken here. And while >> we can expect Peter's excellent work to continue to make big strides, I >> think it may be helpful to keep expectations in check, since we're >> attempting to bridge two very different worlds. Not all life forms that >> thrive on one planet can survive at all on another. >> >> -- >> Richard Gaskin >> Fourth World Systems >> Software Design and Development for the Desktop, Mobile, and the Web >> ____________________________________________________________________ >> ambassa...@fourthworld.com http://www.FourthWorld.com >> >> >> >> >> >> _______________________________________________ >> 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 _______________________________________________ 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
