Date | Commit message (Collapse) |
|
The WebSocket protocol is still undergoing changes and unused.
We won't waste time supporting it until it's finalized and
doesn't break HTTP.
|
|
We use Cool.io internally everywhere now, but preserve
Rev-based models for anybody using them.
|
|
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.
|
|
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.
|
|
This simplifies and disambiguates most constant resolution
issues as well as lowering our identation level. Hopefully
this makes code easier to understand.
|
|
Despite the large number of changes, most of it is code
movement here.
|
|
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.
|
|
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).
|
|
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.
|
|
This release should fix ThreadSpawn green thread blocking issues
under MRI 1.8. Excessive socket closing is avoided when using
Thread* models with Sunshowers (or clients disconnecting
during uploads).
There is a new RevFiberSpawn concurrency model which combines
Rev with the traditional FiberSpawn model.
|
|
This is like the traditional FiberSpawn, but more scalable (but
not necessarily faster) as it can use epoll or kqueue.
|