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.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
