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	doc: misc cleanups and additions for RDoc
	This is also our website, so we need to document the new Cool.io-based concurrency options for users and point existing Rev* users to it.
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-12-26	rainbows/rev/* require/autoload cleanup
	One line of code saved! We'll also avoid loading DeferredChunkResponse which is rarely needed (unlike DeferredResponse).
2010-12-26	rainbows/rev/*: uninident some more
	This makes constant resolution more predictable, we hope.
2010-12-26	rev: split out Rainbows::Rev::Server
	One file per class/module should be easier for new hackers to find. Unindent rainbows/rev/core while we're at it, too.
2010-12-26	rev: unindent, needless autoload
	Deferred* classes will get loaded anyways since Rainbows::Rev::Client hit them in case statements.
2010-07-19	rev: split out deferred chunk logic from unchunked
	Similar to what we do in EM, this avoid unnecessary conditional logic inside more frequently used code paths.
2010-07-19	rev: autoload DeferredResponse
	Some apps never serve static files nor proxy pipes/sockets, so they'll never need to deal with deferred responses.
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-02-11	use Hash#compare_by_identity for performance
	When available (Ruby 1.9), we can use Hash#compare_by_identity to improve performance.
2009-11-24	Rev*: safer client accounting
	Due to the addition of keepalive_timeouts, it's safer to pay a performance penalty and use a hash here instead.
2009-11-18	rev: implement keepalive timeout
	This is a bit trickier than the rest since we have to ensure deferred (proxied) responses aren't nuked.
2009-11-07	rev: split out further into separate files for reuse
	This will make things easier to manage with more Rev-based concurrency models.
2009-11-07	rev/event_machine: simplify keepalive checking a bit
	Since the HTTP parser is frozen during app dispatch, there's no point in checking for HTTP keepalive sooner. Of course we check G.alive as late as possible since we could've received a :QUIT signal while app.call was running.
2009-11-06	cleanup worker heartbeat and master deathwatch
	It turns out neither the EventMachine and Rev classes checked for master death in its heartbeat mechanism. Since we managed to forget the same thing twice, we now have a test case for it and also centralized the code to remove duplication.
2009-11-02	Rev model is the only user of deferred_bodies
	We don't use it in EventMachine since EM has its own built-in ways to handle deferred bodies.
2009-10-30	rev: split out heartbeat class
	This module will be reused in upcoming Rev-derived concurrency models.
2009-10-26	rev: enforce Rev::VERSION >= 0.3.0
	We depend on the ability to create listeners from existing IO objects here.
2009-10-26	rev: do not File.expand_path on result of body.to_path
	Rack::Lint requires File::exist? to be true on this, so there's no need to expand the path name to resolve it here.
2009-10-26	ev_core: do not drop deferred bodies on graceful quits
	Graceful quit means we finish sending everything we have before exiting. Additionally, only signal quits after we've queued the error response up.
2009-10-26	rev/evma: move common code for event models into ev_core
	EventMachine and Rev models seem to be able to share a lot of common code, so lets share. We may support Packet in the future, too, and end up with a similar programming model there as well.
2009-10-26	rev: spell ECONNABORTED correctly
	Odd that Ruby didn't barf on this until now...
2009-10-19	rev: fix static file responses under HTTP/0.9
	Since HTTP/0.9 responses have no headers to write, the on_write_complete handler we rely on never got triggered, leading to additional reads to never get queued up. Additionally, we need to explicitly detect and close client sockets if we've written the last response body since HTTP/0.9 clients never know when it's time to close a connection.
2009-10-19	rev: remove Revactor-specific workaround
	This was blindly copied and pasted from the Revactor code.
2009-10-19	rev: update documentation for this model

2009-10-19	rev: AsyncResponse => DeferredResponse API cleanup
	The "async" moniker wasn't appropriate since this API also handles static files without slurping, so "deferred" is a more appropriate term (even if I have trouble speling words with double conssonants in them). The DeferredResponse.write method now emulates the HttpResponse.write method for consistency.
2009-10-18	rev: async response bodies with DevFdResponse middleware
	This new middleware should be a no-op for non-Rev concurrency models (or by explicitly setting env['rainbows.autochunk'] to false). Setting env['rainbows.autochunk'] to true (the default when Rev is used) allows (e)poll-able IO objects (sockets, pipes) to be sent asynchronously after app.call(env) returns. This also has a fortunate side effect of introducing a code path which allows large, static files to be sent without slurping them into a Rev IO::Buffer, too. This new change works even without the DevFdResponse middleware, so you won't have to reconfigure your app. This lets us epoll on response bodies that come in from a pipe or even a socket and send them either straight through or with chunked encoding.
2009-10-18	rev: fix heartbeat timeouts
	Oops, looks like they were never implemented at all.
2009-10-17	rev: avoid stack overflow through pipelining
	Handling HTTP pipelining through recursion is not good since several hundred kilobytes worth of GET/HEAD requests can be a LOT of GET/HEAD requests...
2009-10-17	rev: handle fully-buffered, pipelined requests
	This leaves us vulnerable to stack overflows through excessive pipelining. The next patch will fix things hopefully.
2009-10-17	refactor graceful shutdowns again, harder
	We use the "G" global constant from the Rev model everywhere to simplify things a little. Test cases are more consistent now, too.
2009-10-17	Rev: simplification to error handling
	on_write_complete has no chance of being called there so remove the unnecessary ensure statement
2009-10-14	documentation updates (mostly on network models)

2009-10-14	Rev: fix error handling for parser errors
	We should try to send 400s back to the client if possible.
2009-10-14	Rev: general module documentation + caveats

2009-10-14	preliminary Rev support
	There is no TeeInput (streaming request body) support, yet, as that does not seem fun nor easy to do (or even possible without using Threads or Fibers or something to save/restore the stack...)