Re: ANN: Iowa 0.9 Released

On Mon, 9 Aug 2004, Kirk Haines wrote:

> On Sun, 8 Aug 2004 22:41:20 +0900, Ara.T.Howard wrote
>
>> iowa sounds a lot like fastcgi.  besides from being a ruby
>> application with all that comes with that, how does it differ?
>>
>>    - is there an object pool, or one responder object?
>>    - does session affinity exist?
>>    - how exactly would one use it 'with' fastcgi?
>
> Iowa is a framework for creating web apps and dynamic web content.  It's
> only affiliation with FCGI is using FCGI as a mechanism for transfering the
> request from the web server to the Iowa process.
>
>
> BROWSER -------> WEBSERVER --[REQUEST_TRANSPORT]---> IOWA
>   ^               |   ^                               |
>   |               |   |                               |
>   -----------------   ---------------------------------
>
>
> The browser sends it's request to the web server.  Through some mechanism,
> the web server identifies that the request should be handled by Iowa, and
> transfers the request to the Iowa process.  Iowa handles the request,
> returning content to the webserver which then returns it to the browser.
>
> The mechanism that I typically use for the webserver to identify requests
> that should go to the Iowa process is a mod_ruby handler.  One uses regular
> Apache directives like <Location> to tell Apache what should be subjected to
> the handler's examination.  The handler, in turn, uses a simple file of
> paths such as:
>
> /
> /index.html
> /my_application
> /images/project_gannt_chart.svg
>
> to know what it should pass on to Iowa and what it should simply let fall
> through for Apache to handle itself.
>
> The FCGI or plain old CGI support replaces the mod_ruby handler.  If one
> does not run mod_ruby, one can use web server directives to decide what
> requests should go to Iowa.  <Location>, <Directory>, mod_rewrite rules,
> whatever.  Those requests get to the Iowa process by going through a CGI or
> FCGI program that basically just constructs an Iowa::Request object (which
> is like a lightweight serializeable Apache::Request) and sends it to the
> Iowa process's communication's socket.  Iowa handles the request, generating
> the content, and returns it back down the socket to the CGI or FCGI program,
> which then in turn sends the content back to the webserver as its own.

so, in essence, the 'middle bit' of mod_ruby, fcgi, or cgi is needed to lookup
the iowa persistent process - to find it and connect stdin, stdout, stderr,
etc.  you couldn't simply map an apache handler to iowa application since they
are persistent and apache would then fire one up for each request...  would it
be difficult to use mod_fastcgi to manage the whole thing?  i mean, that
module has support to start persistent applications and then direct requests
to them via sockets...  (i'm just wondering out loud here)

does the mod_ruby or cgi bit manage initially starting the iowa app, or is
this a separate step?


> The Iowa process is multithreaded.  When a request comes into it, it
> dispatches a thread to handle the request.

so one must avoid doing anything that could potentially block an entire ruby
process, like flock, or no new requests would get served - correct?


<snip content good content generation description>

> My goal with Iowa is for the framework to stay out of my way as much as
> possible.  It is a LOT like Rails in intent, but very different in
> implementation.  It straddles the seperation of content from code somewhere
> between Rails and CGIKit.  Rails lets one embed code in the content.  CGIKit
> is very zealous in requiring a binding to create an additional level of
> indirection between content and code.  Iowa keeps the code out of the
> content, but has a few code-like markup tags and allows direct method calls
> from within the code.  One of the coming additions, again thanks to David
> Naseby for writing the seed to get it started, is the ability to basically
> inline programmatically generated images and things of that nature into a
> page generated by Iowa.

this is a useful comparison.  i looked into using cgikit a while ago and found
it just a we bit too restrictive for those times when you just need to brute
force something...

> The genesis of this was David's desire to display a Gannt table generated
> with the SVG library from Sean Russel.  He hated the idea of saving it off
> to a temporary file just to display it once, so he hacked Iowa so that he
> could inline it.  A method call generates the SVG image and Iowa takes care
> of making sure that the URL in the content, when accessed, invokes that
> method.  So the SVG image gets generated on the fly without ever having to
> be stored on disk, but as the developer, all you have to do is provide the
> method to generate the SVG.  It's pretty neat.

this is very cool.

> Like I mentioned earlier, I've been using it for more than two years on a
> wide variety of business applications and complete web sites, and I continue
> to use it and develop on it because it's just plain fast and easy to get
> results.
>
> Now that Iowa can be used with WEBrick, that opens up a whole new avenue of
> possibilities for me, too.  It's trivial to start a WEBrick + Iowa server,
> which makes it fantastic for testing things and for working on developing an
> Iowa application or Iowa powered web site, even if one doesn't intend to use
> WEBrick in production to serve the application or site.  And with exerb I
> should also be able to write a complete web app including all of the support
> content such as images and other static content and wrap that all up as a
> single executable that can just be installed and executed.

i like the sound of using webrick, i would assume some sort of handler does
away with the need for the mod_ruby/cgi 'middle man'?

> Wow.  This ended up being long.  Hopefully it helps explain better than I
> did yesterday just what Iowa is, though.

yes.  thank you - i'm going to be doing some web development soon and have
been out of that realm for about 12 months, so it's survey time again...

cheers.

-a
--
===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: [phone]
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. 
|   --Dogen
===============================================================================