Making the move...
Collabyrinth VPN
collabyrinth at sympatico.ca
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:
>
>
> 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
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
More information about the use-livecode
mailing list