Andre Garzia wrote:
This thing by REAL Software begs one questions: "How it handles concurrent
requests". FastCGI can multiplex requests, so there is a real chance your
software will be answering to more than one guy at the same time. How does
it handle that?
My understanding is that RB supports threads, so while comments in their
forum suggest it's not trivial to use them well at least they're
available and with FastCGI that helps a lot, for all the reasons you've
noted here earlier.
So how does it works for them? Does it maintain application state for each
of the clients in memory or does it simply converts everything to
HTML/JS/CSS and allows all the state to be managed on the client side?
In my initial reading of their outline it seems a reasonably good mix of
server and client-side processing.
Since we already have RevServer and have been enjoying Rev CGI for
years, the biggest advantage RB/Web offers is in delivering native
JavaScript/CSS/HTML on the browser.
In many respects that isn't all that different from what Toolbook did
more than a decade ago, as I noted here in 2006:
<http://article.gmane.org/gmane.comp.ide.revolution.user/83744>
IMO such an initiative would be advantageous for RunRev, much more so
than wrassling with a plugin. If anyone would have asked me before they
got started I would have been glad to share what I learned from
Allegiant's experiments with their SuperCard plugin, Roadster; there are
many good reasons it was allowed to die. The plugin API seems
seductively simple at first, but when you're looking to provide
capabilities as broad as LC or SC it starts to get murky and weird
pretty quickly, and costs multiply in a hundred unexpected ways.
One of the great things about JavaScript/CSS/HTML is that it's all text,
and LC is unusually adept at parsing and concatenating text gracefully
and efficiently. So not only do you get a browser-native solution that
runs on every web-capable device, you can make it at home in your spare
time without needing to monkey around with complex APIs or binary data
structures - it's all just text.
As I suggested all those years ago, it wouldn't be all that hard for the
LC community to take this up as a FOSS project.
The challenge with that is that FOSS is often a rich man's game,
requiring the contributor to have enough retained earnings from paid
work to be able to devote sufficient time to giving code away for free
while still keeping a roof over their head.
I've started down the road of making a Rev-to-JS/CSS/HTML converter, and
while I've deployed specialized variants of that for specific client
projects (thanks for you help on getting one of those started, Andre!)
it's a heckuva lotta work to make a generalized solution, and my clients
are keeping me too busy to pursue it much further for the next few months.
But the idea's out there, free for the taking if anyone has the time to
devote to seeing it through. Toolbook showed us one way to do this in
xTalk, and a lot of fairly big organizations shipped a lot of great
courseware and other web apps with it. Making a LC-based system for
this wouldn't be trivial, but more tedious than difficult, requiring
more time than brains. :)
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
_______________________________________________
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
