ANN: Iowa 0.9 Released

[Kirk Haines]

A new version of the Iowa web application framework has been released. This
release shows a major jump in version numbers. Iowa has been in use for
over two years in many successful production applications and web sites, and
with the feature additions in this release, is very close to what I want for
a 1.0 release.

It can be downloaded from

http://rubyforge.org/projects/iowa

and documentation can be found at

http://enigo.com/projects/iowa


What is Iowa?

In short, it is a web application framework that features a seperation of
code from layout and that is very simple to use to create both full featured
web based applications as well as dynamically generated web page content.
Iowa applications run as discrete backend processes, seperate from the web
server processes. The name stands for Internet Object for Web
Applications. All components are objects, and session handling is done on
the server side, leaving the developer free to concentrate on the details of
the application.

The most tested mode of operation is from an Apache web server using
mod_ruby to run a custom mod_iowa.rb handler that handles communications
between Apache and the Iowa application. It can be used via a standard CGI
interface, making it usable on any web browser that supports this. There is
also FCGI support.

New in this release is WEBrick support. Using WEBrick, it is extremely easy
to make an Iowa powered application or even an entire web site available.
The WEBrick support, though new, seems quite stable and performs
surprisingly well. There is an example that one can run in the
examples/webrick directory of the 0.9 release. One should be able to:

cd examples/webrick/iowa
ruby iowa_webrick.rb

to start it. Then just point your web browser at http://localhost:2000 to
check it out. Thanks to David Naseby for giving me the seed of code that
got me started in implementing this.

As of this release, Iowa also now runs on Windows, and it supports
multipart/form-data forms (file uploads).

Documentation is available at

http://enigo.com/projects/iowa

Specific documentation on the webrick support and on some of the new
features is forthcoming.

For those of you who are comparing, Iowa solves many of the same problems
that Rails does, but with a very different architecture. It can be used
with both ActiveRecord to handle model data or with the Kansas library
(found on Rubyforge, and with a new release coming today, as well).


Check it out! Let me know if you have any questions. I'm always eager to
help out however I can. You can email me directly, IM me at
(e-mail address removed), or subscribe to the iowa mailing list at Rubyforge.


Thanks,

Kirk Haines

 

[Ara.T.Howard]

The most tested mode of operation is from an Apache web server using
mod_ruby to run a custom mod_iowa.rb handler that handles communications
between Apache and the Iowa application. It can be used via a standard CGI
interface, making it usable on any web browser that supports this. There is
also FCGI support.

kirk-

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?

cheers.

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

 

[Kirk Haines]

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.

The Iowa process is multithreaded. When a request comes into it, it
dispatches a thread to handle the request. In a nutshell, this handler
identifies which component the request needs to go to and passes
responsibility to the component. Each piece of content, whether it be a
full web page or just a piece of a page such as a header, footer, or
navigation bar/box, is a component, and each component is an object. Each
component is constructed of a layout section and a code section, with an
optional bindings section.

An example of layout:

<div class="inputTable">
<form oid="save">
Name: @user<br/>
Email: <input type="text" oid="email" size="40" maxlength="80"><br/>
Comment: <textarea rows="5" cols="65" oid="text"/><br/>
<input type="submit" oid="save" value="Save">&nbsp;&nbsp;
<input type="submit" oid="cancel" value="Cancel">
</form>
</div>

<table class="resultsTable">
<tr>
<th>Name</th>
<th>Email</th>
<th>Comment</th>
</tr>
<repeat oid="entryList">
<tr>
<td>@entry.name</td>
<td>@entry.email</td>
<td>@entry.text</td>
</tr>
</repeat>
</table>
<Footer oid="footer"/>


It's just plain old HTML, for the most part. The only difference is that
some of the tags have an oid= attribute in them. OID stands for object id,
and it's existence is the cue to Iowa that Iowa needs to step in and do
something dynamic there. In addition to that, there are some pieces of text
that are prefaced with an @, such as @user and @entry.name. @ means that
what follows is the name of a method to call. What is returned from the
method call will be inserted into the content at that point.

The only other piece that differs from a static HTML document is the
<repeat> tag. Iowa doesn't allow code within the layout, so for doing
things like looping through a list of values or conditionals, it employs a
very small set of additional HTML-like tags. That <repeat> tag tells Iowa
that it needs to look for a binding, entryList, that should define a list
and an iterator.

In the code section, the binding for entryList looks like this:

entryList {
item = entry
list = entries
}

'entries' is a method that returns an array to iterate through.

def entries
@db.transaction do
@db.roots.sort.collect {|k| @db[k]}
end
end

And 'entry' is just an accessor:

attr_accessor :entry

A quick sidenote here. There are some tags, such as <ul>, that Iowa knows
are tags that inherently deal with lists of stuff. If one were to do this:

<ul oid="entryList">
<li>@entry.name</li>
</ul>

Iowa would know that you mean for that <ul> to iterate over the entryList.
<table> is another tag like this. If I took out the <th> tags in the above
table, I could have written it like this:

<table oid="entryList">
<tr>
<td>@entry.name</td>
<td>@entry.email</td>
<td>@entry.text</td>
</tr>
</table>

The only other nonstandard item in there is the <Footer/> tag. A Footer is
a seperate component that defines the standard footer for the site. That
tag just includes an instance of the Footer component into this one.


The end result is that it is very easy to contruct applications or other
dynamic content. You write all of the content layout in a standard way.
You can even use a WYSIWYG tool for this if you want. Then you use Ruby to
write the meat. Iowa takes care of making sure that form inputs get placed
in the proper writers or accessors, and takes care of session management and
all of the general administrative tasks, so all the developer or developers
have to do is concentrate on creating the substance.

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.

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.

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.

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


Thanks,

Kirk Haines

 

[Mauricio Fernández]

A new version of the Iowa web application framework has been released. This
release shows a major jump in version numbers. Iowa has been in use for
over two years in many successful production applications and web sites, and
with the feature additions in this release, is very close to what I want for
a 1.0 release.

It can be downloaded from

http://rubyforge.org/projects/iowa

I have just uploaded Iowa 0.9 to the preliminary Ruby Production Archive
(RPA) repository (http://rubyforge.org/frs/?group_id=265):

$ rpa query -x iowa
Matching available ports:
name: iowa
version: 0.9-1
classification: Top.Library.Development
requires: log4r
description: Web application framework for Ruby

IOWA is a web application framework featuring a separation of content from
code, moderate resource usage, works on Ruby 1.6.x and 1.8.x, and decent
performance. It's been used on many production systems over the last two
years.


Installation/upgrade is achieved with

$ rpa install iowa

and happens atomically, as usual.

=== More information on RPA and rpa-base at
http://rpa-base.rubyforge.org

 

[Michael Neumann]

]
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 sounds really good. But is it possible to generate "real" images
(jpg, png) on-the-fly? Generating the image is no problem, but
associating the image data with an URL is a bit harder. I tried this in
Borges, and it did work, but it was a bit awkward IIRC.

And, is there a way to split the .iwa files into pure Ruby files (.rb)
and binding files (.whatever)? Or allow Ruby code at the beginning of an
iwa file without the need to surround it with <% ... %>. For example, I
don't want to change the .iwa file if a binding changes. And I want the
Ruby source code to be syntax-highlighted (do you have a vim syntax
definition for .iwa files? ;-).

Thanks in advance!

Regards,

Michael

 

[Michael Neumann]

Kirk Haines wrote:

May I ask another question? ;-)

I'd like to use Active Records with IOWA. Have you tried it out? I know
that there's Kansas... but I like AR very much.
I probably have to write my own session class which connects to the
database and set AR's connection to this one for each request. I believe
that each request is handled by it's own thread, but all request of the
same session are not handled by one and the same thread, right?

Regards,

Michael

 

[Kirk Haines]

On Mon, 9 Aug 2004 02:30:20 +0900, Michael Neumann wrote

This sounds really good. But is it possible to generate "real" images
(jpg, png) on-the-fly? Generating the image is no problem, but
associating the image data with an URL is a bit harder. I tried this
in Borges, and it did work, but it was a bit awkward IIRC.

That's the idea. David just sent me his stuff a week or so ago, and I've
been pretty busy, so I haven't had a chance to do much with it, yet.

And, is there a way to split the .iwa files into pure Ruby files
(.rb) and binding files (.whatever)? Or allow Ruby code at the
beginning of an .iwa file without the need to surround it with <%
... %>. For example, I don't want to change the .iwa file if a
binding changes. And I want the Ruby source code to be syntax-
highlighted (do you have a vim syntax definition for .iwa files? ;-).

I'll add the splitting of bindings from the .rb files. I've thought about
it a bunch but haven't done it because I'm lazy. Off the top of my
head, I'll probably use .bnd for a bindings file unless someone has a better
suggestion. So:

Index.html
Index.iwa
Index.bnd

And yes, in fact, you don't need to wrap ruby code in the <% %> in a .rb
file. That was a legacy thing that I got rid of quite a while ago. If one
does that, it still works, so the old stuff still works without changes, but
there is no need to do it now unless one is putting the code section and the
html section into the same file.

Index.iwa
-----
import 'Header'
import 'Footer'

class Index < Iowa::Component

# blah blah blah

end

# Bindings are still in the .rb file, mostly because of laziness.
<?
fooList {
item = foo
list = foos
}
?>
-----

For vim, I just added .iwa to the list of extensions that the ruby syntax
highliting module recognizes.


Hope that helps,

Kirk

 

[Kirk Haines]

Kirk Haines wrote:

May I ask another question? ;-)

I'd like to use Active Records with IOWA. Have you tried it out? I
know that there's Kansas... but I like AR very much. I probably have
to write my own session class which connects to the database and set
AR's connection to this one for each request. I believe that each
request is handled by it's own thread, but all request of the same
session are not handled by one and the same thread, right?[/QUOTE]

Right. Each seperate request is handled by a thread that terminates after
the response is sent back.

I looked at Active Record some time ago, but not enough details are popping
into my head at the moment to be sure this is right, but...

If you use the Iowa connection pool, DbPool, you can probably make use of
something that I did for it to support Kansas to also support ActiveRecord.
In your Iowa::Application subclass:

attr_accessor :dbpool

def initialize(*args)
@dbpool = Iowa:bPool.new
('Mysql','localhost','mydb','myuser','mypwd',3,300) {|dbh|
# The 3 is the number of connections in the pool, and the
# 300 is the number of seconds that a reaper thread sleeps
# between checks for connections that have become orphaned
# and hanged.
# This block will be executed when the connection pool
# creates its connections. It receives the database handle
# and can then do anything to it that it wants. Whatever
# is returned from the block is what the connection pool
# will actually store in the pool.
#
# So, at this point, use the connection to setup your AR
# connection, I believe.

ar_connection
}


Something like that should let you use the connection pool with
ActiveRecord. Then, in your code, when you need to do something with the
database:

application.dbpool.getConnection do |ar_connection|
# do your queries
end


Make sense? That's exactly how I do it with Kansas, and it works well and
lets me keep the number of db connections very low.

If you try it and it works, let me know and send me the code and I'll get
something added to the documentation that specifically addresses using
ActiveRecord with Iowa.


Thanks,

Kirk Haines

 

[Kirk Haines]

On Mon, 9 Aug 2004 02:30:20 +0900, Michael Neumann wrote

This sounds really good. But is it possible to generate "real" images
(jpg, png) on-the-fly? Generating the image is no problem, but
associating the image data with an URL is a bit harder. I tried this
in Borges, and it did work, but it was a bit awkward IIRC.

Okay. I worked on this a bit today, and it has proved pretty simple.

To use it one writes a method that generates the image data and then calls
session.resource_url with the image data and the mime type. That method
will return the URL that will access the image data.

def image
# blah blah whatever you have to do to generate the image data.
session.resource_url(image_data,'image/gif')
end


Then in your HTML, just put the call to image wherever you need the URL:

<img src="@image" alt="Inline generated image">

That's it. Easy to use. I think I will setup session.resource_url so that
it can take a block. If you call it as above, the resource is generated
when the page that references it is generated, then cached until retrieved.
If one passes in a block, the block will be responsible for generating the
resource data, and thus resource generation can be defered until it is
actually requested, and it need not be cached at all.


Kirk Haines

 

[Ara.T.Howard]

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?

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 :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Kirk Haines]

On Mon, 9 Aug 2004 23:11:21 +0900, Ara.T.Howard wrote

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)

Yep. The middle bit is just a transport mechanism to get the request from
the web server to the Iowa process and back again.

Iowa could definitely be setup to run directly as an FCGI process, too. I
should do that, as an option. Should be pretty trivial to setup.

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

The Iowa app runs as a seperate bit. This allows some flexibility to, for
example, run the Iowa process on a seperate machine from the web server.
Down the road I am planning on making it possible to have multiple Iowa
processes running across multiple machines for load balancing with session
affinity, so that fits the model of the Iowa process _generally_ being
seperate, too.

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

Hrm. Yeah. Interesting point. I've never had to deal with that problem
myself, but I can see where it could be troublesome. One thing I have toyed
with for about as long as I have been using Iowa is the idea of having as an
option a forking model instead of a threading model to handle connections.
With Ruby's all-within-a-process, there would be some potential performance
advantages to a forking model, especially if it were a forking model with
preforking. I just never have done it because I never have needed it.

this is very cool.

I have it basically done. There are a few refinements that I want to put
into it later, but I am going to roll an example usage of it into the
examples section of the download and release an update today that has this
inline URL/content generation capability in it.

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'?

Yep. The model that I used for webrick was to combine the Iowa and WEBrick
processes. So you fire up one process, and it serves regular image/static
HTML/cgi content through WEBrick's regular capabilities, and Iowa content
goes through the Iowa side of the process. It is extremely simple to start
it up. Take a look at the examples/webrick part of the release. You should
be able to just run examples/webrick/iowa_webrick.rb and everything should
just work.

Performance also seems pretty decent. I have not tested it extensively, but
a few quick tests suggest that for Iowa content it's about 70% of the speed
of apache + mod_ruby, and I assume most of that is simply the difference in
speed between WEBrick and Apache. I'll be doing some more extensive tests
later with larger & more complex content generation, but that sort of speed
is pretty reasonable. On a PIII 800Mhz running Gentoo Linux, that
translates to something in the low 20s of requests per second for a typical
moderately sized & moderately complex page.

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...

Well, give me a shout if you have any more questions. I'm always happy to
give a hand where I can.


Kirk Haines

 

[Ara.T.Howard]

Iowa could definitely be setup to run directly as an FCGI process, too. I
should do that, as an option. Should be pretty trivial to setup.


The Iowa app runs as a seperate bit. This allows some flexibility to, for
example, run the Iowa process on a seperate machine from the web server.
Down the road I am planning on making it possible to have multiple Iowa
processes running across multiple machines for load balancing with session
affinity, so that fits the model of the Iowa process _generally_ being
seperate, too.

and, of course, the mod_fastcgi module doesa all of this (including session
affinity).

Hrm. Yeah. Interesting point. I've never had to deal with that problem
myself, but I can see where it could be troublesome. One thing I have toyed
with for about as long as I have been using Iowa is the idea of having as an
option a forking model instead of a threading model to handle connections.
With Ruby's all-within-a-process, there would be some potential performance
advantages to a forking model, especially if it were a forking model with
preforking. I just never have done it because I never have needed it.

i'm looking into writing a monitoring app that uses an sqlite backend - it
uses fcntl based locks - so this is a big issue (note to any/all of you using
sqlite as a db for web apps)

Yep. The model that I used for webrick was to combine the Iowa and WEBrick
processes. So you fire up one process, and it serves regular image/static
HTML/cgi content through WEBrick's regular capabilities, and Iowa content
goes through the Iowa side of the process. It is extremely simple to start
it up. Take a look at the examples/webrick part of the release. You should
be able to just run examples/webrick/iowa_webrick.rb and everything should
just work.

Performance also seems pretty decent. I have not tested it extensively, but
a few quick tests suggest that for Iowa content it's about 70% of the speed
of apache + mod_ruby, and I assume most of that is simply the difference in
speed between WEBrick and Apache. I'll be doing some more extensive tests
later with larger & more complex content generation, but that sort of speed
is pretty reasonable. On a PIII 800Mhz running Gentoo Linux, that
translates to something in the low 20s of requests per second for a typical
moderately sized & moderately complex page.

very slick - i like this approach the best.

Well, give me a shout if you have any more questions. I'm always happy to
give a hand where I can.

will do - thanks for the info

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