rainbows.git - Unicorn for sleepy apps and slow clients

Date	Commit message (Collapse)
2010-12-28	complete Rev => Coolio renaming
	We use Cool.io internally everywhere now, but preserve Rev-based models for anybody using them.
2010-12-27	coolio*: favor Coolio over Rev
	We still use and define Rev internally, but that's mostly just manual labor of converting stuff over.
2010-12-27	coolio_fiber_spawn: decrease CPU usage for keepalive
	Blindly resuming fibers every second is a waste of cycles, we can use the ZZ hash in regular FiberSpawn to resume expired fibers on an as-needed basis. While we're at it, merge the keepalive-timeout class into the heartbeat, there's no reason to have separate timers and classes here.
2010-12-27	initial cool.io support
	Cool.io is the new name for Rev. We'll continue to support Rev until Cool.io breaks backwards compatibility. Rev may not be supported if Cool.io is.
2010-10-22	code shuffling for kgio
	Despite the large number of changes, most of it is code movement here.
2010-10-21	unicorn 2.x updates + kgio
	We get basic internal API changes from Unicorn, code simplifications coming next.
2010-09-28	start using kgio library
	It removes the burden of byte slicing and setting file descriptor flags. In some cases, we can remove unnecessary peeraddr calls, too.
2010-08-26	split out accept() callers to acceptor module
	Trying to avoid adding singleton methods since it's too easily accessible by the public and not needed by the general public. This also allows us (or just Zbatery) to more easily add support systems without FD_CLOEXEC or fcntl, and also to optimize away a fcntl call for systems that inherit FD_CLOEXEC.
2010-07-23	rename parse_range => make_range!
	It's a destructive method, and it does more than just parsing.
2010-07-22	enable Range: responses for static files for most models
	The FileStreamer class of EventMachine (and by extension NeverBlock) unfortunately doesn't handle this. It's possible to do with Revactor (since it uses Rev under the covers), but we'll support what we can easily for now.
2010-07-19	refactor response handling for each concurrency model
	This will give each concurrency model more control over particular code paths and serving static files.
2010-07-10	doc: avoid documenting internals on RDoc website
	Since we suck at building websites, we just rely on RDoc as a website builder. And since Rainbows! is an application server (and not a programming library), our internal API should be of little interest to end users. Anybody interested in Rainbows! (or any other project) internals should be reading the source.
2010-07-08	restore Rainbows::HttpResponse.write for Cramp
	Cramp monkey patches Rainbows internals for WebSockets support and we forgot about it. Add a new integration test to ensure this continues to work in the future (and force us to update the test for newer Cramp).
2010-07-04	refactor response body handling for sendfile(2)
	This hopefully allows the "sendfile" gem to be required anywhere in the Rainbows!/Unicorn config file, and not have to be required via RUBYOPT or the '-r' command-line switch. We also modularize HttpResponse and avoids singleton methods in the response path. This (hopefully) makes it easier for individual concurrency models to share code and override individual methods.
2010-06-18	prefer Array#[] lookup to Array#first/Array#last
	Array#[] lookups are slightly faster under both rbx and 1.9, and easier to read.
2010-03-28	cleanup: avoid redundant REMOTE_ADDR logic
	Every concurrency model does this the same way. This removes the Rainbows::Const::LOCALHOST constant and may break some existing apps that rely on it.
2009-12-22	common Rainbows.sleep(nr) method
	We'll export this across the board to all Rack applications to sleep with. This provides the optimum method of sleeping regardless of the concurrency model you choose. This method is still highly not recommended for pure event-driven models like Rev or EventMachine (but the threaded/fiber/actor-based variants are fine).
2009-12-22	new RevFiberSpawn concurrency model
	This is like the traditional FiberSpawn, but more scalable (but not necessarily faster) as it can use epoll or kqueue.