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-26	remove unnecessary "::" constant prefixing
	It's ugly to look at.
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-09	respect client_body_buffer_size in Unicorn 3.1.0
	This is only needed for concurrency options that do not use TeeInput, since TeeInput automatically handles this for us.
2010-10-22	unindent most files
	This simplifies and disambiguates most constant resolution issues as well as lowering our identation level. Hopefully this makes code easier to understand.
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-27	rainbows/rev/core: tiny cleanup
	Remove an unused constant.
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-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-05	rev: properly enable post-fork sendfile() usage
	We need to load sendfile-using parts after the "sendfile" library is loaded.
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.
2009-12-16	get rid of the magic EvCore.setup
	It gets in the way of Rev/EM-based models that won't use EvCore. It doesn't actually do anything useful except making an extra layer of indirection to follow.
2009-12-04	rev: do not initialize a Rev::Loop in master process
	It may make it harder to switch between concurrency models with SIGHUP this way...
2009-11-29	rev/core: don't set IOBuffer.default_node_size
	iobuffer 0.1.3 already sets this.
2009-11-28	common Rainbows.accept method

2009-11-28	rev/core: fix stupid syntax error :<
	Broken in 145185b76dafebe5574e6a3eefd3276555c72016
2009-11-27	rev/core: set IO::Buffer.default_node_size if possible
	It can noticeably improve performance if available. ref: http://rubyforge.org/pipermail/rev-talk/2009-November/000116.html
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-07	ev_core: cleanup handling of APP constant
	It'll make development of future ev_core-derived things easier, hopefully.
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.