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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
