OT: Real competition for revlets

Richard Gaskin ambassador at fourthworld.com
Thu Dec 16 09:41:43 EST 2010


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




More information about the Use-livecode mailing list