Players in HTML5 - ETA for Full Functionality?
blueback09 at gmail.com
Thu Feb 25 14:02:15 EST 2016
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 <ambassador at fourthworld.com
> 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
> 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
> 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
> Given that the only execution engine commonly available in browsers is
> web browser requires either of two approaches:
> a) Translate LC-native objects to browser-native HTML/CSS, and LC-native
> 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
> 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.
> 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++
> 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
> Option b) lets all your LC objects scripts go along for the ride since the
> 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
> 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
> Ambassador at FourthWorld.com http://www.FourthWorld.com
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode