Making the move...

[Richard Gaskin]

Dan Shafer wrote:
> With the caveat that I am hardly a Rails expert and certainly have not done
> a lot of work with Rev on the server side either, let me see if I can
> clarify my earlier point here. I know that what I'm going to say is probably
> so trivial to many reading this thread that it will seem like I'm just off
> base, but I'm trying to make the issue I see really starkly clear.

I'm certainly no Ruby/Rails expert either, but I am among those
attracted to the word "impossible". :)  Even though we've moved past
that original point, there may be some interesting things to explore here.

This one got a bit long (from me?  Gosh, when did I ever write a long 
post? <g>), so I added section headers to try to make it an easier read:


PARSING/ASSEMBLING THE CLIENT OUTPUT
------------------------------------

> With PHP or Ruby on Rails, 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.
> 
> So for example (and I realize this is so simplistic that it may not be
> sufficiently illustrative), in a .rhtml (rubified HTML) file, you might find
> this construct:
> 
> It is now <%= Time.now %>

In Transcript:

   It is now [[the time]]

You run that through the merge function:

   put merge("It is now [[the time]]")

...and you get:

   It is now 4:44 PM

More interesting is that you don't need to use literal expressions with
merge; you can pass it variables as well, with any number of bracketed 
statements, allowing you to make whole pages of snippets which have all 
the smarts of Transcript embedded throughout, processed in a single 
merge() call.

And of course we all know about the other powerful text manipulation
stuff in Transcript like chunk expressions and such, so we can move on
to the bigger question of how we hook the engine into the web
transaction process.


HOOKING REV INTO THE SERVER TRANSACTION
---------------------------------------

Most of the RoR documentation makes reference to FastCGI as the
deployment mechanism for Ruby, and recommends using a specialized server 
app, WEBrick, for testing locally before deployment.  It seems Rev has 
both of these covered.

If I read Pierre's article at 
<http://istream.homeunix.com/insead/index_en.html> correctly, it seems 
we can use Rev as a daemon (at least on Linux), providing a 
stay-resident option just as one would do with other engines like Perl, 
Python, etc.

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.

Because the interest in using Ruby on web servers is relatively recent,
I can't imagine there's anything in the server configuration that
couldn't also be done with Rev (or Python or PHP other popular engines).
In both cases you need to install the engine and set up the server so it
knows what to do with it.

There may be some reason that Rev can't be used with FastCGI per se, but 
given that it will run as a daemon on Linux offhand I don't know what 
that could be.  If anyone here knows it would be interesting to find 
out, and even more interesting to find out if you've been able to use 
Rev with FastCGI successfully.



PROS AND CONS OF REV AND RUBY
-----------------------------

Beyond the configuration, there are two main differences between a Rev
and a Ruby solution:  OOP and Rails.

The first is the age-old procedural vs. OOP argument.  There are
benefits both ways, and I dare not suggest we need to answer that big
abstract question here. :)

Where Ruby really shines is in Rails:  there's a lot of code there,
well-crafted code.  You'd have to write that yourself to get to the same
level of development productivity with Rev.

But consider this about the origins of Ruby:

     Matz's primary design consideration is to make programmers
     happy by reducing the menial work they must do, following
     the principles of good user interface design. He stresses
     that systems design needs to emphasize human, rather than
     computer, needs.
     <http://en.wikipedia.org/wiki/Ruby_programming_language>

Sound like another language we know?  :)

Personally, I think the only reasons we're reading about Ruby on Rails
rather than Revolution on Rails are that both Ruby and Rails are open 
source, and there is no similar framework for Rev. While Rev isn't 
inherently OOP as Ruby is, it has its own favorable tradeoffs which make 
it quite attractive in its own right.



FRAMEWORKS AND DEPLOYMENT OPTIONS
---------------------------------

So what if someone took that much time to craft a web app framework in
Transcript?


I'm reminded of Andre's presentation at the first RevCon West and later
that year at the Euro RevCon in Malta:  web applications driven by Rev
on the server.

Andre took the whole stay-resident paradigm one step further, 
implementing a WEBrick-like server built with Rev. While there are no 
doubt drawbacks to using Rev instead of Apache for heavy-load 
deployments, there are some upsides for more modest uses: it's small, 
reasonably efficient, and much, much simpler to set up than Apache + 
Ruby + GEMS + Rails + whatever else is needed to make RoR run.

Andre's system started with mchttpd.mc, a stack Scott Raney put together
to show off the engine's socket support with a surprisingly small set of
scripts that act as a web server.  It can be downloaded here:

<ftp://ftp.metacard.com/MetaCard/mchttpd.zip>

It's no Apache nor is it meant to be, but it does show off the engine's
capabilities in a practical solution for specialized uses, such as an
extranet for remote workgroups.

For larger loads it might be beneficial to use Apache, set up to use Rev
as is commonly done for Ruby (I'd sure love to see benchmarks if
anyone's set up both).  But for a good many intranet and extranet uses a 
Rev-based server has some merits.

Andre took Dr. Raney's modest example and expanded it greatly, setting
up a number of applications in a modular way so that he could just write 
a small stack when he needs another app, drop it on the server, and it's 
available when called by name in the URL (Andre, did I recall that 
correctly?).

And if memory serves, he even used directory names as part of the
program's logic, similar to how RoR uses them.

Maybe we could entice Andre to write an article for revJournal outlining
this?  Something like "Andre on Rails" would be great to read.


> 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 before you jump in my face again, go back and re-read the caveat at the
> beginning of this message. :-)

Please accept my apologies if it seemed I was jumping in your face.
Sometimes my enthusiasm for the language is stronger than the clarity of
my writing.

My intention was simply to encourage the readers here to consider
comparisons of goals rather than implementations, in hopes that it might
inspire more Andre-quality solutions implemented in ways that take
advantage of people's current knowledge and the things Transcript has
going for it.



FUTURE POSSIBILITIES
--------------------

While we wait to see if anyone here has time to try setting up Rev with
FastCGI (we already know it works well as a traditional CGI), I would 
enourage those interested in web apps grab Dr. Raney's mchttpd.mc and 
play with it a while.   It's a thing of beauty to just open the stack, 
click the "Start" button, and call it with your browser.

And then consider this:  If Rev is still free to use as a faceless 
server process (it used to be; not sure if that still applies), there's 
an opportunity to encourage folks to learn Transcript by bundling a 
Transcript framework with it which takes care of the tedious meat of 
such applications, leaving the developer free to focus on the 
domain-specific logic but with the ease of Transcript and a much simpler 
installation than RoR.

And when they find they can make GUI admin tools for just $49 with Rev 
Media it gets even better. :)

The missing link is the killer app made with it.  RoR was virtually 
unheard of before BaseCamp took off, showing the world how powerful and 
flexible RoR is.  If we had an app of similar scope and appeal I have no 
doubt that as long as the engine is free for such uses and the scripts 
are open source it would attract considerable attention.

Ah, the limitless possibilities....

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com