Another web challenge: state

[Richard Gaskin]

Forgive my seeming obsessiveness over this thread, but having ported 
some rather non-trivial projects to the web over the last few years it's 
a topic of especially keen interest to me, always eager to find a 
panacea only to find El Dorado instead.

I've been running Rev-based CGIs well for years on Dreamhost, Bluehost, 
and other shared-hosting services, and we've heard many good reports 
from others here about running RevServer on a far broader range of systems.

One of the challenges with CGI is that you need to design very lean, 
because the app needs to be initialized, do everything it needs to do, 
and then die all during the user's wait for the response from the server.

One upside to this is that it allows the engine to work effectively as a 
multi-threaded process, in that each request spawns a discrete instance 
completely separate from any other.

But this also poses challenges in terms of how you preserve state 
information between requests.  You can use cookies or server text files 
or database records for that, but for many apps you'll need to implement 
something because the app will die the moment the current request is 
fulfilled.

A way to avoid this is to have the app always running, as a sort of 
daemon process, listening on a specified socket for incoming instructions.

The problem with that is that it'll only be allowed on dedicated servers 
or some VPSes; I don't know of any shared host that allows custom daemons.

This issue came to light in a thread I came across in the RB forums, 
eager as I am to learn more about their implementation.

This thread notes how Dreamhost -- where I run a great many Rev CGIs, 
including the blog at LiveCodeJournal.com -- recently nixed an RB app 
because it was attempting to maintain an open socket:
<http://forums.realsoftware.com/viewtopic.php?f=23&t=40397>



Earlier Chipp noted the many difficulties in staying up on the various 
implementations of HTML/JS/CSS across the many browsers any good web app 
will need to support.  While there is a reasonably broad subset of 
features reliable across most browsers, it does indeed take a little 
time to turn up the resources that list which are which, and to develop 
habits which avoid the more exotic new goodies which fail in many 
browsers (how nice the world would be if IE would simply die the death 
it deserves after so many years of thumbing its nose at well-published 
standards).

It seems that some aspects of the server side of the equation, such as 
state maintenance, can be equally challenging.

So far from my research into the RB implementation it seems that while 
it is indeed an excellent tool for some tasks, it offers only a little 
more than what TookBook did more than a decade ago, relying on a subset 
of available classes which can be exported for web deployment.  As you 
browse through the forum, you'll find the answer to many questions there 
is "you can't do that".

This is not to detract from what RB has accomplished, which is indeed 
very useful for certain types of apps, esp. database apps such as the 
one featured in their demo.

But it does not seem to attempt to translate the full range of desktop 
capabilities for the web, so expectations for such tools may be best met 
if adjusted somewhat conservatively.

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