Players in HTML5 - ETA for Full Functionality?

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com