Players in HTML5 - ETA for Full Functionality?

[Matt Maier]

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
> 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
>  ____________________________________________________________________
>  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:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>