[OT] Opinions about On-Rev

J. Landman Gay jacque at hyperactivesw.com
Fri Apr 17 21:21:01 EDT 2009

Joe Lewis Wilkins wrote:

> I have found this whole subject so far over my head that I'm 
> embarrassed. Can anyone sight some sort of reference that just "might" 
> get me off of my desktop. I am soooo uneducated on this topic. Simply 
> stated, what's this for, why is it needed and what does it let us do 
> that we can do now? There MUST be others who are just as much in the dark.

It's kind of hard to explain if you don't create web pages or have a 
familiarity with how they are written. But in a nutshell, web pages 
written in pure HTML are static. Whenever you see a page that does 
something dynamic -- buttons with different rollover states, data that 
changes depending on live user input, dynamic content of any type -- 
those actions must be scripted into the page using a second, scripted 
language like JavaScript or PHP. The scripted language is integrated 
into the same page as the HTML code and the server interprets the 
scripts and shows you dynamic content.

Up until now, anyone who wanted dynamic content on a web page had to 
learn one of those other languages. What has just happened is that 
Runtime has figured out a way to allow a web server to work with our 
familiar xtalk, and allow that to be embedded into a web page instead of 
one of the other languages. This is big stuff.

The server needs to be set up in a particular way to allow this, and as 
of now, only Runtime has that setup in place. They have made their web 
service available so we can take advantage of this new capability. Their 
setup pretty much matches industry standards in terms of features and 
capability -- except for this remarkable scripting feature which no one 
else has. There is nothing to lose by changing to Runtime's web hosting 
service, and everything to gain if you want to write web pages using the 
language we know and love.

For years now, the Rev engine has always had the capability to work with 
a server as long as it was set up as a CGI service. This is a 
complicated and tedious task in general, but once it was set up it works 
well. (This method isn't going away, by the way. It will still be 
functional for those who want it.) However, with the new HTML-integrated 
capabilities, CGIs are no longer needed. You can write HTML and Rev 
script in the same web page and your users will see content based on 
whatever your scripts do. You don't have to worry about any of the 
complexities of CGIs because none of that matters any more (permissions, 
engines, Apache installation, missing libraries, line endings, etc. All 
moot now.)

Anyone who's had to work with the old-style CGIs will find the new 
method liberating. One of the hardest things to do was debug a CGI; it 
was very much like working with HC version 1.0 where the only way to 
know what a variable contained was to put its contents into the message 
box. If you got a script error, it was up to you to figure out the 
problem, because the clues were sparse if they existed at all. That's 
all over with now. RR provides a live debugger that lets you step 
through the scripts on a web page just as though you were working in a 
stack. That alone is worth the price of admission for web page authors.

For me, I haven't seen such a cool thing since I was gobsmacked by the 
ability to run a stack from a remote server in one line of script.

Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com

More information about the use-livecode mailing list