Hello, Today I'm proud to release Rack 0.2. = Rack, a modular Ruby webserver interface Rack provides a minimal, modular and adaptable interface for developing web applications in Ruby. By wrapping HTTP requests and responses in the simplest way possible, it unifies and distills the API for web servers, web frameworks, and software in between (the so-called middleware) into a single method call. The exact details of this are described in the Rack specification, which all Rack applications should conform to. == Supported web servers The included *handlers* connect all kinds of web servers to Rack: * Mongrel * Mongrel/Swiftcore (require it before Rack.) * WEBrick * FCGI * CGI Any valid Rack app will run the same on all these handlers, without changing anything. == Supported web frameworks The included *adapters* connect Rack with existing Ruby web frameworks: * Camping These frameworks include Rack adapters in their distributions: * Ramaze * Maveric * Racktools::SimpleApplication == Available middleware Between the server and the framework, Rack can be customized to your applications needs using middleware, for example: * Rack::URLMap, to route to multiple applications inside the same process. * Rack::CommonLogger, for creating Apache-style logfiles. * Rack::ShowException, for catching unhandled exceptions and presenting them in a nice and helpful way with clickable backtrace. * Rack::File, for serving static files. * ... All these components use the same interface, which is described in detail in the Rack specification. You can choose to use them exactly in the way you want. == Convenience If you want to develop outside of existing frameworks, implement your own ones, or develop middleware, Rack provides many helpers to create Rack applications quickly and without doing the same web stuff all over: * Rack::Request, which also provides query string parsing and multipart handling. * Rack::Response, for convenient generation of HTTP replies and cookie handling. * Rack::MockRequest and Rack::MockResponse for efficient and quick testing of Rack application without real HTTP round-trips. == rackup rackup is a useful tool for running Rack applications, which uses the Rack::Builder DSL to configure middleware and build up applications easily. rackup automatically figures out the environment it is run in, and runs your application as FastCGI, CGI, or standalone with Mongrel or WEBrick---all from the same configuration. == Where can I get it? You can download Rack 0.2 at http://chneukirchen.org/releases/rack-0.2.0.tar.gz http://rubyforge.org/projects/rack Alternatively, you can checkout from the development repository with: darcs get http://chneukirchen.org/repos/rack (Patches using "darcs send" are most welcome.) == Installing with RubyGems A Gem of Rack is available. You can install it with: gem install rack I also provide a local mirror of the gems (and development snapshots) at my site: gem install rack --source http://chneukirchen.org/releases/gems == History * March 3rd, 2007: First public release 0.1. * May 16th, 2007: Second public release 0.2. * HTTP Basic authentication. * Cookie Sessions. * Static file handler. * Improved Rack::Request. * Improved Rack::Response. * Added Rack::ShowStatus, for better default error messages. * Bug fixes in the Camping adapter. * Removed Rails adapter, was too alpha. == Contact Please mail bugs, suggestions and patches to <mailto:firstname.lastname@example.org>. Darcs repository ("darcs send" is welcome for patches): http://chneukirchen.org/repos/rack You are also welcome to join the #rack channel on irc.freenode.net. == Thanks to * Michael F., for the helpful discussion, bugfixes and a better Rack::Request interface. * Christoffer S., for the Rails adapter. * Tim F., for the HTTP authentication code. * Armin Ronacher, for the logo and racktools. * Aredridel, for bug fixing. * Gary W., for proposing a better Rack::Response interface. * Alexander Kellett for testing the Gem and reviewing the announce. * Marcus Rückert, for help with configuring and debugging lighttpd. * The WSGI team for the well-done and documented work they've done and Rack builds up on. == Copyright Copyright (C) 2007 Christian N. <http://purl.org/net/chneukirchen> Rack is freely distributable under the terms of an MIT-style license. == Links Rack:: <http://rack.rubyforge.org/> Rack's Rubyforge project:: <http://rubyforge.org/projects/rack> Camping:: <http://camping.rubyforge.org/> Ramaze:: <http://ramaze.rubyforge.org/> Maveric:: <http://maveric.rubyforge.org/> racktools:: <http://lucumr.pocoo.org/trac/repos/racktools/> Christian N.:: <http://chneukirchen.org/> Happy hacking and have a nice day, Christian N. f1063711f228d19875a3211d71308b5c rack-0.2.0.tar.gz fad21b5fac8790fe6bf295fefdac5816 rack-0.2.0.gem
on 2007-05-16 19:20
on 2007-05-16 23:59
Hi Christian, On 16-May-07, at 11:20 AM, Christian N. wrote: > servers, web frameworks, and software in between (the so-called > middleware) into a single method call. > [snip] > * Rack::Request, which also provides query string parsing and > multipart handling. > * Rack::Response, for convenient generation of HTTP replies and > cookie handling. > * Rack::MockRequest and Rack::MockResponse for efficient and quick > testing of Rack application without real HTTP round-trips. Does this mean that, using Rack, I can make my own request/response objects up and push them into the web framework? That would be very very good. What about Merb? Have you discussed this with Ezra yet? Cheers, Bob ---- Bob H. -- tumblelog at <http:// www.recursive.ca/so/> Recursive Design Inc. -- weblog at <http://www.recursive.ca/ hutch> -- works at <http://www.recursive.ca/>
on 2007-05-21 00:31
Bob H. <email@example.com> writes: >> Rack provides a minimal, modular and adaptable interface for >> multipart handling. >> * Rack::Response, for convenient generation of HTTP replies and >> cookie handling. >> * Rack::MockRequest and Rack::MockResponse for efficient and quick >> testing of Rack application without real HTTP round-trips. > > Does this mean that, using Rack, I can make my own request/response > objects up and push them into the web framework? That would be very > very good. Exactly. > What about Merb? Have you discussed this with Ezra yet? We talked some time ago, and he was interested in it. Haven't heard of him since, though.