Players in HTML5 - ETA for Full Functionality?

Thu Feb 25 14:11:42 EST 2016

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 <blueback09 at 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 <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
> _______________________________________________
> 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