Making the move...

Fri Mar 24 23:04:11 EST 2006

On Mar 16, 2006, at 8:13 AM, Richard Gaskin wrote:
>
> I would imagine one could also set up Apache to use Rev for server- 
> side includes, using settings similar to what's used for Ruby or PHP.

I'm coming in here late on this but it's of great interest and very  
relevant, because somehow, not really knowing any better I just  
stumbled on this two years ago and now we use SSI's which execute Rev  
CGI's throughout our web site.  yes and  double yes.. works great.  
Assuming you have a Rev Engine installed, CHMOD 755 and other cgi's  
are working. There is no "set up" required at all for SSI's

  <!--#include virtual="/cgi-bin/get_story_listing.cgi" -->

or iFrame

<iframe name="archiveIndex" border="0" width="130" height="140" src="/ 
cgi-bin/buildArchivesIndex.cgi">

  We do not see *any* slow down. Of course those CGI's are not doing  
anything very complex. Maybe I'm way out of my depth here and what we  
are doing is very "baby face" compared with the kinds of things you  
are saying RoR can do ...

On Mar 15, 2006, at 3:05 PM, Dan Shafer wrote:
> Furthermore, the execution of that CGI script would require an event
> to be sent via a form button or a JavaScript onLoad() command; it's  
> not just
> automatic.

With SSI exec it *is* automatic. I don't see any execution slow down.  
And there is no round trip to the client server client server  that a  
JavaScript onLoad() does (I think)

Dan, if your definition of a web app really is:

>  a Web *app* consists of a collection of 1 or more
> templates -- HTML files with embedded command and function calls --  
> that
> execute in a server-side scripting language interpreter running on the
> server. All Web pages with this embedded script code are run  
> through the
> scripting language interpreter on the server, where the command is  
> carried
> out and some content is generated to replace the command call  
> before the
> page is sent to the HTTP server to return to the client.

We are *already*  doing this with Rev for several years now (and I'm  
pretty sure I'm not the only one, I got into this with Andu Novac  
when this was all metacard years ago... he still around?) and it  
works great, even without fastCGI...the fact that Rev is called on  
each hit doesn't seem to be an issue at all. Of course my suexec log  
is crazy big and scary for tech support at the data center who threw  
up a "Denial of Service Attack Underway-Change Your
Root Password Now!" red flag when they looked at it... "You mean your  
web pages are calling those CGI's on every hit? Wow, if I tail the  
log those Revolution CGI's are executing every few milliseconds...   
But your site still blazes?" Oh boy... I need to set up a cron to  
null that thing once a day! And, if you ssh in and run top.. the CPU  
shows it is still half a sleep... "kustum Illai" (Tamil) = "no problem"
=======

OK Marty, for us poor "we only know xTalk paupers" if you are  
lurking... I've put up some CGI's  on our site and sent you the URL  
off list (I don't want to post that on this forum... if anyone else  
wants to see them, ask me off list)

Since I am a "coding primitive" you should be able to understand it  
all easily enough. In my old age I'm doing more commenting. The model 
(s) is very simple: if the CGI is an SSI then it executes and builds  
parts of the page before the page is sent. Nothing could be simpler.  
This usually involves fetching some template or  code chunks in the  
SSI folder. I always try to avoid hard coding HTML in the CGI and  
almost always externalize even small chunks to small files. this has  
the advantage that you can delegate code maintenance... someone says  
"Can I add a new link to the side bar" and you say "sure.. just add  
an <li>Some New link</li> to this file" and they never touch the CGI.

And for icing on the coffee cake, and if you combine Rev cgi with XML  
and XSL you have some really interesting possibilities.

Just go to this page:

http://www.himalayanacademy.com/teaching/stories/

When you hit that page, the page itself re-builds the list of stories  
instantly... there is no round trip before  the page is served.

OK now go here:

http://www.himalayanacademy.com/teaching/stories/enter_stories.shtml

and enter a bogus story (no problem I will delete later, this site is  
not public, I mean it's not linked to any top pages, just put your  
name in there somewhere.)

Now go back to

http://www.himalayanacademy.com/teaching/stories/

and you will see your new story added to the list... click on your  
story.. viola, it comes back to you as a web page...tell me if you  
see the slightest delay in the service. Any PHP doing the same thing  
would be 2 to 5 times slower. I put all the related files to this  
little framework in the folder called "stories." and the cgi emails  
me that a story was just entered...

The input page takes form data, the rev CGI grabs an XML template  
pops in the data from the form, saves an XML document that calls an  
XSL stylesheet (that was actually the biggest learning curve, getting  
my head around XSLT) The index page has an embedded call to a Rev CGI  
that simply sets the default directory and then spits back links  
tagged to "the files" ... how easy is that? an xTalk baby could write  
the code, but the possibilities are a big mind boggling. In fact I've  
been kind or "stuck on the fence" as to whether to use this model for  
some site areas, or to use a database model where content is stored  
in a PostGREsql dBase and we pages are built on the fly by calling up  
records... but then I kind of "stumbled" on this little model for  
this stories site and realized it could be scaled up and do the same   
thing using flat files-- i.e. for a finite number of files, the XML- 
XSL flat file respository  with top level xhtml pages with Rev CGI's  
embedded as SSI's could eliminate having to talk any data base. It  
also means the files are accessible for editing directly with FTP vs.  
having to set up some GUI to access the same content from inside  
PostGreSQL .

I can't compare to RoR.. because I don't know it... but as I said  
before... we have not found anything we can't do with Rev. The only  
nuisance is no session variables, but once we get Rev up under  
FastCGI that also goes away. And if we can't get it with FastCGI,  
then on the new server we will do it Pierre's way.. either way we  
will have a Rev Daemon up and running full time.

Of course this could be a case of, like those Japanese... making a  
success out of a bad system... but is sure seems simple and easy. We  
the coders, Apache and the CPU, and remote users all seem to have no  
problem with it. And if you don't know PERL or PHP and Cold Fusion =  
some kind of icecream, And Ruby on Rails is what little boys dop to  
tease goldie locks in kindergarten,  and Java is definitely what you  
drink in the morning, then you don't have much choice. I am awed by  
all of you who know so many languages but at the same time somehow  
thankful that the only language we do know is transcript,  I haven't  
hit any walls yet, and it looks like the sky is the limit.

Sivakatirswami

On Mar 15, 2006, at 3:05 PM, Dan Shafer wrote:

> Furthermore, the execution of that CGI script would require an event
> to be sent via a form button or a JavaScript onLoad() command; it's  
> not just
> automatic.
>
> I am NOT suggesting it would be impossible to remedy these issues  
> in Rev.
> Nor am I suggesting that the overhead of this processing is so  
> onerous that
> using Rev CGI solutions is impractical. All I'm trying to say is  
> that there
> is a pretty fundamental difference here between invoking a script  
> language's
> command directly and being forced to explicitly call a CGI function  
> that in
> turn executs a script command.
>
> Now if I understand things on the Rev side correctly -- and there  
> are a lot
> of folks here who know more about this than I do -- the only way to  
> get a
> Rev script to run is as a CGI. That means, among other things, that  
> you'd
> have to minimally create a text file with a script called "on  
> startup" and
> save that script as an executable CGI script. So you'd end up  
> dealing with a
> text file, permissions, and an indirect call to the contents of the  
> script
> file to accomplish the same thing that one line of embedded Ruby  
> code does
> in RoR. Furthermore, the execution of that CGI script would require  
> an event
> to be sent via a form button or a JavaScript onLoad() command; it's  
> not just
> automatic.
>