Making the move...

Collabyrinth VPN collabyrinth at
Thu Mar 16 13:34:43 EST 2006

Forgive the intrusion from a 'lurker', but as I've learned so much from 
you all the last three months, it's time I gave something back.

I'm developing using Ruby on Rails on both Windows XP Pro SP2 & 
(Knoppix) Linux simultaneously.

Rev works just fine with FastCGI. Fwiw, I'd be happy to set up some 
benchmarks and publish the results next week, if it helps.

A brief general comment. I use and modify the Ruby code to handle the 
'unseen' parts, if you will, and Rev to generate what the user sees on 
the websites. I see Rev as complementary to ROR, and it seems to work 
well. A good mix.

Cheers from Canada
Peter Elliott

Richard Gaskin wrote:

> 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:
> ------------------------------------
>> 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 <%= %>
> 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.
> ---------------------------------------
> 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 
> <> 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.
> -----------------------------
> 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.
>     <>
> 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.
> ---------------------------------
> 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, 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:
> <>
> 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.
> --------------------
> 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 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:
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:

More information about the Use-livecode mailing list