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