Players in HTML5 - ETA for Full Functionality?

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Players in HTML5 - ETA for Full Functionality?

Sannyasin Brahmanathaswami
 
Are players expected to work in HTML5? I created a really simple stack with a button to fetch a remobe URL to an MP3 file, set the filename of a player on the card to that URL and start playing.

really simple… works on desktop like a charm.  

Fails in HTML5 standalone made with LC 8dp14  

I already bug reported this, but thought to ask here.  

streaming remote audio/video will be mission critical for us.  

BR
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Martin Koob
I tried the same thing with a remote URL to an mp4 video file.  Same result it plays in the IDE but not in HTML5.

I checked your bug report http://quality.livecode.com/show_bug.cgi?id=16870  and see that the response from Peter Brett that 'Player support has not yet been implemented in the HTML5 engine'.

Hopefully Peter can respond here with an ETA for Player support in the HTML5 engine.
 
What types of video and audio files will it be expected to play?

Thanks.

Martin

Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Peter TB Brett
On 08/02/2016 14:37, Martin Koob wrote:

> I tried the same thing with a remote URL to an mp4 video file.  Same result
> it plays in the IDE but not in HTML5.
>
> I checked your bug report http://quality.livecode.com/show_bug.cgi?id=16870
> and see that the response from Peter Brett that 'Player support has not yet
> been implemented in the HTML5 engine'.
>
> Hopefully Peter can respond here with an ETA for Player support in the HTML5
> engine.
>
> What types of video and audio files will it be expected to play?

Hi Martin and Brahmanathaswami,

There is no current ETA for implementing player support in the HTML5
engine.  I can confirm that it *won't* be in LiveCode 8.0, however.

                                          Peter

--
Dr Peter Brett <[hidden email]>
LiveCode Open Source Team

LiveCode 2016 Conference: https://livecode.com/edinburgh-2016/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Sannyasin Brahmanathaswami
So there is no way to play audio or video via *any* method in an HTML5 standalone?

In a world of YouTube, iTune, Pandora etc..

Not having this capability in LC  seems... well (I will refrain from explicatives...)

Any other options to play besides the player? Leverage web kit? Create a  mini web page on our server for display of video/audio and then use the browser widget in an HTML5 app? (TBD) ?

This is a critical mass function/requirement...


On February 24, 2016 at 12:12:45 AM, Peter TB Brett ([hidden email]<mailto:[hidden email]>) wrote:

Hi Martin and Brahmanathaswami,

There is no current ETA for implementing player support in the HTML5
engine. I can confirm that it *won't* be in LiveCode 8.0, however.

Peter
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Stephen Barncard-4
On Wed, Feb 24, 2016 at 6:09 PM, Sannyasin Brahmanathaswami <
[hidden email]> wrote:

> Not having this capability in LC  seems... well (I will refrain from
> explicatives...)
>

if a monk swears in the woods, will anyone hear?  (ducking...)

Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Monte Goulding-2
In reply to this post by Sannyasin Brahmanathaswami

> On 25 Feb 2016, at 1:09 PM, Sannyasin Brahmanathaswami <[hidden email]> wrote:
>
> Not having this capability in LC  seems... well (I will refrain from explicatives...)

Did you expect such a major and technically difficult port of the platform to all arrive in one blob without any progressive development? As is HTML5 deployment will be quite functional for quite a number of apps. It seems reasonable to me that those that don’t need or can work around some of the currently un-ported features should have the opportunity to use it.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Sannyasin Brahmanathaswami
I realize my tone is a bit "strident" ... sorry about that.

Of course we don't expect something all at once, my problem and the problem of many here is that while the rest of the digital revolution has forged head with huge advances in multi-media delivery. LC is still many years behind.

 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....

"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?

I will test the browser widget myself (I'm assuming it will work in an HTML5 standalone.)

BR...



On February 24, 2016 at 5:18:00 PM, Monte Goulding ([hidden email]<mailto:[hidden email]>) wrote:

Did you expect such a major and technically difficult port of the platform to all arrive in one blob without any progressive development? As is HTML5 deployment will be quite functional for quite a number of apps. It seems reasonable to me that those that don’t need or can work around some of the currently un-ported features should have the opportunity to use it.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Peter TB Brett
On 25/02/2016 05:59, Sannyasin Brahmanathaswami wrote:

> So back to my question: is there another way to play media using
> other means beside a player?

Not that I'm aware of.

> I will test the browser widget myself (I'm assuming it will work in
> an HTML5 standalone.)

No, the browser widget is not available in HTML5 standalones (and indeed
actually *can't* be for the time being due to the way that it works).

I posted recently-ish about the problems making certain types of
LiveCode features (such as "wait" and the "URL" chunk) work in the HTML5
engine.  I'm sure you can find the e-mail in the list archives.  Those
same considerations apply to many of the other yet-to-be-implemented
features.

If you'd like to see multimedia and network connectivity in Community
HTML5 standalones, you can speed up their delivery by finding a solution
to those problems other than "redefine half the LiveCode Script
language" or "rewrite the entire LiveCode engine".

You don't need to "bang the drum" about HTML5 Player control support.
*I KNOW*.  I will implement it as soon as 1) it becomes technically
possible to do so and/or (2) a developer has time to work on it.

If you want it sooner: you can accelerate (1) by contributing the open
source project; and you can accelerate (2) by contributing to the open
source project or giving us more money (e.g. by buying an HTML5
deployment license, or by getting a Business license and purchasing
dedicated developer time).

By the way, the same considerations apply to all the other "critically
important feature requests" you so frequently put into the bug tracker,
Brahmanathaswami.

                                        Peter


--
Dr Peter Brett <[hidden email]>
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Terry Judd-2
Apologies for hijacking this thread somewhat but Peter could you possibly
comment on the likelihood of clipboard support being added to HTML5 in the
near (or middle) future. I understand there are potential security
concerns around use of the clipboard but it would be good to hear your
thoughts on how these might be accommodated (or not).

Regards,

Terry...

On 25/02/2016 5:10 pm, "use-livecode on behalf of Peter TB Brett"
<[hidden email] on behalf of
[hidden email]> wrote:

>On 25/02/2016 05:59, Sannyasin Brahmanathaswami wrote:
>
>> So back to my question: is there another way to play media using
>> other means beside a player?
>
>Not that I'm aware of.
>
>> I will test the browser widget myself (I'm assuming it will work in
>> an HTML5 standalone.)
>
>No, the browser widget is not available in HTML5 standalones (and indeed
>actually *can't* be for the time being due to the way that it works).
>
>I posted recently-ish about the problems making certain types of
>LiveCode features (such as "wait" and the "URL" chunk) work in the HTML5
>engine.  I'm sure you can find the e-mail in the list archives.  Those
>same considerations apply to many of the other yet-to-be-implemented
>features.
>
>If you'd like to see multimedia and network connectivity in Community
>HTML5 standalones, you can speed up their delivery by finding a solution
>to those problems other than "redefine half the LiveCode Script
>language" or "rewrite the entire LiveCode engine".
>
>You don't need to "bang the drum" about HTML5 Player control support.
>*I KNOW*.  I will implement it as soon as 1) it becomes technically
>possible to do so and/or (2) a developer has time to work on it.
>
>If you want it sooner: you can accelerate (1) by contributing the open
>source project; and you can accelerate (2) by contributing to the open
>source project or giving us more money (e.g. by buying an HTML5
>deployment license, or by getting a Business license and purchasing
>dedicated developer time).
>
>By the way, the same considerations apply to all the other "critically
>important feature requests" you so frequently put into the bug tracker,
>Brahmanathaswami.
>
>                                        Peter
>
>
>--
>Dr Peter Brett <[hidden email]>
>LiveCode Open Source Team
>
>LiveCode 2016 Conference https://livecode.com/edinburgh-2016/
>
>_______________________________________________
>use-livecode mailing list
>[hidden email]
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Sannyasin Brahmanathaswami
In reply to this post by Peter TB Brett
Points taken.. sorry to be a burr in the side...

Thanks for listening.  I'll look at the budgets and see what we can do from here.

All the best to the team.

On February 24, 2016 at 8:11:33 PM, Peter TB Brett ([hidden email]<mailto:[hidden email]>) wrote:
You don't need to "bang the drum" about HTML5 Player control support.
*I KNOW*. I will implement it as soon as 1) it becomes technically
possible to do so and/or (2) a developer has time to work on it.

If you want it sooner: you can accelerate (1) by contributing the open
source project; and you can accelerate (2) by contributing to the open
source project or giving us more money (e.g. by buying an HTML5
deployment license, or by getting a Business license and purchasing
dedicated developer time).

By the way, the same considerations apply to all the other "critically
important feature requests" you so frequently put into the bug tracker,
Brahmanathaswami.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Richard Gaskin
In reply to this post by Sannyasin Brahmanathaswami
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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]
> 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
>  ____________________________________________________________________
>  [hidden email]                http://www.FourthWorld.com
>
>
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Mark Waddingham-2
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 <[hidden email]> 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 <[hidden email]
>> 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
>> ____________________________________________________________________
>> [hidden email]                http://www.FourthWorld.com
>>
>>
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Mark Waddingham-2
In reply to this post by Richard Gaskin
When it comes down to it, there is a direct parallel between wanting to use native html5 elements in a LiveCode html5 app and wanting to use native (system provided) controls on mobile.

There are still a couple of technical hurdles to overcome to make this possible in the html5 port, but for the most part it comes down to having a bridge between LCB and JavaScript when running in a browser. You can view the JS APIs as no different from system APIs on any other platform and in the same way as LCB can bridge (albeit in a very low-level way right now) to C APIs directly, the Html5 engine will eventually be able to bridge to JS APIs.

Mark.

Sent from my iPhone

> On 25 Feb 2016, at 18:23, Richard Gaskin <[hidden email]> 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
> ____________________________________________________________________
> [hidden email]                http://www.FourthWorld.com
>
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Matt Maier
In reply to this post by Mark Waddingham-2
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 <[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]
> >> 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
> >> ____________________________________________________________________
> >> [hidden email]                http://www.FourthWorld.com
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> [hidden email]
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Sannyasin Brahmanathaswami
In reply to this post by Matt Maier
On February 25, 2016 at 9:02:29 AM, Richard Wrote:
> 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.


Agreed. I guess I was being naive in the understanding of the level of changes required to encompass media delivery, and I will certainly keep my expectations in check... My apologies for banging the drum.

 We *can* fulfill our media delivery "vision"  on LC/Mobile and we can build a web UI using Rev igniter... so I'll be content to develop in that space for now.

I hereby officially switch hats  to "infinite patience"

Richard Wrote:

"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.

That's kind of what I thought could work, even as an interim solution. Our use case doesn't really require the full spectrum of native LiveCode player parameters. Open, play, pause and stop and dismiss would suffice for 95% of the requirements. In my naivete, targeting the innerHTML with a small html5 Video tag seemed trivial... obviously I am wrong.

 This is more than you need to know, but part of the "back story" and "urgency" here was a hope  to keep LiveCode at the forefront of our in house toolbox. Another new young person -- who already went thru the Livecode University has switched to learning Python and will soon be developing HTML5 on that platform, because  it needs to run in a browser/WordPress iFrame.  Of course I have to shake my head at how many hours it will take him to do the smallest framework... and the scope of what he will be able to accomplish relative to a full LC stack will be highly compromised...even the scope on the spec of that project was chopped down by 85%...as "not doable now..."  when the whole original spec could have been done in LiveCode in a week(s)... (except for the video streaming)

We had to reach out to a HTML5 pro in Belarus, to get a leg up on how to do the first one and now we hope to learn how to do it ourselves....having Python skills on the team I suppose will be userful, I would have much preferred he focused on LiveCode because I believe it would have been to our greater advantageands more "fun" for him in the long run.  But, I can run his modules inside the browser widget in our next LC Mobile app... so we are OK for now.  And it's going to take him soooo long to get to where he wants to be that probably the HTML5 thing in LC will be ready even before he can think about module #2...

Officially now wearing the hat of "infinite patience."

BR


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Richard Gaskin
Sannyasin Brahmanathaswami wrote:

 >  We *can* fulfill our media delivery "vision"  on LC/Mobile and we
 > can build a web UI using Rev igniter... so I'll be content to develop
 > in that space for now.

A web UI is just text - HTML and CSS.  LiveCode is uncommonly good for
processing text.  Whether using RevIgniter or any other framework or
just task-specific code, what gets delivered to the browser is text of a
sort LiveCode is very good at helping to produce.


 >  This is more than you need to know, but part of the "back story"
 > and "urgency" here was a hope  to keep LiveCode at the forefront of
 > our in house toolbox. Another new young person -- who already went
 > thru the Livecode University has switched to learning Python and will
 > soon be developing HTML5 on that platform, because  it needs to run
 > in a browser/WordPress iFrame.

Python doesn't run in a browser any more than LiveCode does.  An iFrame
isn't at all Python-specific, it's an HTML tag (though for compatibility
with iOS browsers he may want to use scrolling DIVs with XMLHttpRequest
instead; last time I had frame-dependent content iPads didn't render it
well so per Apple's tech notes I revised it with DIVs loaded via XHR).

Web UIs are just text - HTML and CSS.  Both Python and LiveCode are good
for processing text, but there's an argument that it's a little easier
and perhaps even faster in LiveCode.  Whether using Python or LiveCode
or anything else, what gets delivered to the browser is text.

Python's a fine language.  But so is LiveCode.  Both have similar use
cases, though given the early state of Python deployment packages for
mobile I think it's safe to suggest LC is more mature for native mobile
apps.   And given the integration of GUI elements as native objects in
LC compared to the traditional approach Python takes in which GUIs are
an afterthought, I'd say LC has at least a modest edge there too.

But for delivering web UIs, both do well at text processing and that's
really all that task is as far as the work done on the server.  And
although I'd love to see more head-to-head benchmarks, what little I've
seen suggests LC may be slightly more efficient in some areas than
Python (chunk expressions are truly wonderful).

The one area where Python has an unquestionable advantage is the size
and engagement of its audience.  Sooooooo many libraries available for it.

We'll get there too, but in the meantime all work in either language
means a lot of unique code, and LC is every bit as solid a choice as Python.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Richard Gaskin
In reply to this post by Matt Maier
Matt Maier wrote:
 > Thanks for that overview Richard, it helped me!

If you read that post to the end you should get a medal. :)  More
long-winded than even my user group presentations.  Glad it was useful.


 > 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?

That's a deep question.

An old friend of mine suggested, "The key to programming is finding the
right dividing lines."

That applies to so much, from factoring code to managing teams, and with
client-server apps I don't believe there's a single best answer.

Consider three example apps:  calculator, animated greeting card, and
RSS aggregator.

With the calculator you could go either way, depending on the nature of
the calculation.  If it's just arithmetic it probably makes the most
sense to do it all in the client, But I have one medical app where the
caluclations are based on values in lookup tables that would be
cumbersome if we had to first download them to the client, so for that
the client is pretty slim and it just sends the input values to the
server who does the lookups and the arithmetic on them and sends back
the answer.

An animated greeting card could conceivably be done on a server using a
canvas object on the client side with web sockets or other method by
which the canvas gets updated from the server for every frame.  But
animations are computationally expensive, and if serving a lot of user
the server would have to maintain quite a high load, and pushing out
each frame is a lot of ongoing traffic, so for that one I'd put
everything on the client.

With an RSS aggregator, all the client really wants is a list of news
stories, but to get those news stories requires some process to download
them (and hopefully politely, within the update limits specified by the
publisher in the feed), parse them, sort them, filter out the irrelevant
ones, rank the rest, and then wrap 'em up in HTML for display.   If the
client had to do all the work it would put more load on the publishers
than is truly needed, and require a lot of work making for a slow UI.
If you had a server-side process that maintained the feeds in question
then most of the work is done only once, publisher servers aren't
overtaxed, and the client gets only the final output HTML (or perhaps
XML or JSON in which the client could do the HTML wrapping itself).

Three simple and fairly common uses cases, but only one of them has
anything close to a simple answer.  Like so much in life, we just have
to look at the problem at hand, pick our dividing lines as best we can
with what we can know at the outside, and be willing to revise as we
learn more.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

ScottR
In reply to this post by Sannyasin Brahmanathaswami
Two qualifications: I haven't followed this thread closely, and I haven't
played a great deal with the HTML5 build.  That said, does an HTML5
standalone have the ability to interact with the HTML of the surrounding
page?

If yes, it would seem to be relatively straightforward to do what most
HTML apps do, which is displaying video content in an iFrame, or embedded
video on the same page.  Perhaps this is even how player support will
eventually by provided by the LiveCode guys.  But if you need a solution
now, maybe this route is an option.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 2/6/16, 7:57 PM, "use-livecode on behalf of Sannyasin Brahmanathaswami"
<[hidden email] on behalf of [hidden email]>
wrote:

>
>Are players expected to work in HTML5? I created a really simple stack
>with a button to fetch a remobe URL to an MP3 file, set the filename of a
>player on the card to that URL and start playing.
>
>really simpleŠ works on desktop like a charm.
>
>Fails in HTML5 standalone made with LC 8dp14
>
>I already bug reported this, but thought to ask here.
>
>streaming remote audio/video will be mission critical for us.
>
>BR



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Players in HTML5 - ETA for Full Functionality?

Mark Waddingham-2
In reply to this post by Matt Maier
On 2016-02-25 20:23, Matt Maier wrote:
> 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?

Yes - building an HTML5 standalone is equivalent to building a
standalone for another platform, it gives you an app which runs locally
on the client. Any server access you do using similar techniques as
those other platforms - for example, by using url requests.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123