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