Players in HTML5 - ETA for Full Functionality?

Thu Feb 25 14:23:00 EST 2016

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