That was too abstract and hypothetical for me to be sure I followed correctly.
In the approach the Livecode team is taking now, is it accurate to say that the html5 standalone bundles up the livecode engine with any app-specific objects/scripts and pushes the whole thing into the client browser, such that all of the (supportable) functionality runs client-side? On Thu, Feb 25, 2016 at 11:11 AM, Mark Waddingham <m...@livecode.com> wrote: > 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 > _______________________________________________ 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
