From niklas+rainbows at lanpartei.de  Wed Jul  7 11:26:40 2010
From: niklas+rainbows at lanpartei.de (Niklas Hofer)
Date: Wed, 7 Jul 2010 17:26:40 +0200
Subject: Websocket Handshake 76
Message-ID: <20100707172640.26fe0ce8@wigowyr>

Hey

 I just tried to implement the new Websocket Handshake [1] into
Rainbows/Sunshowers. I think I almost succeeded (tests and chrome
passing), but I had to hack something and I want your opinion over it:

 In order to complete the new handshake, the server must use 8 bytes
from the incoming body. Because Rainbows uses the HTTPParser and
checking for the "Content-Length" field and the HTTP-like Websocket
request does not supply such a field, no body is forwarded to the
underlying app stack. (0.94.0: lib/rainbows/base.rb:72).

My suggestion: Set an unused key in the env, for example 'hack.buf' and
use this in lib/sunshowers/websocket.rb.

Is this the right way (TM)?
May there be a better name for the env key?

with regards,
Niklas

[1]
http://axod.blogspot.com/2010/06/websocket-gets-update-and-it-breaks.html
-- 

 _ o                         o    |    o       >    =            o)
  /\    - =   <             (|/   |   \|)               \       (| 
 | \                        /)    |    (\          \  _ /       / \
 
The game of life is a game of boomerangs.  Our thoughts, deeds and words
return to us sooner or later with astounding accuracy.


From normalperson at yhbt.net  Wed Jul  7 16:38:49 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 7 Jul 2010 13:38:49 -0700
Subject: Websocket Handshake 76
In-Reply-To: <20100707172640.26fe0ce8@wigowyr>
References: <20100707172640.26fe0ce8@wigowyr>
Message-ID: <20100707203848.GA21844@dcvr.yhbt.net>

Niklas Hofer <niklas+rainbows at lanpartei.de> wrote:
> Hey
> 
>  I just tried to implement the new Websocket Handshake [1] into
> Rainbows/Sunshowers. I think I almost succeeded (tests and chrome
> passing), but I had to hack something and I want your opinion over it:
> 
>  In order to complete the new handshake, the server must use 8 bytes
> from the incoming body. Because Rainbows uses the HTTPParser and
> checking for the "Content-Length" field and the HTTP-like Websocket
> request does not supply such a field, no body is forwarded to the
> underlying app stack. (0.94.0: lib/rainbows/base.rb:72).
> 
> My suggestion: Set an unused key in the env, for example 'hack.buf' and
> use this in lib/sunshowers/websocket.rb.
> 
> Is this the right way (TM)?
> May there be a better name for the env key?

Hi Niklas,

I haven't gotten a chance to look into the new WebSocket updates, but
can't you just read the 8 bytes off env["rack.input"]?

  env["rack.input"].read(8)

-- 
Eric Wong

From niklas+rainbows at lanpartei.de  Thu Jul  8 10:41:49 2010
From: niklas+rainbows at lanpartei.de (Niklas Hofer)
Date: Thu, 8 Jul 2010 16:41:49 +0200
Subject: Websocket Handshake 76
In-Reply-To: <20100707203848.GA21844@dcvr.yhbt.net>
References: <20100707172640.26fe0ce8@wigowyr>
	<20100707203848.GA21844@dcvr.yhbt.net>
Message-ID: <20100708164149.37178aed@wigowyr>

Am Wed, 7 Jul 2010 13:38:49 -0700
schrieb Eric Wong <normalperson at yhbt.net>:

> I haven't gotten a chance to look into the new WebSocket updates, but
> can't you just read the 8 bytes off env["rack.input"]?
> 
>   env["rack.input"].read(8)
> 

I tried that without success, it does not give me anything (seems to
be empty), even if I rewind it beforehand.

Niklas
-- 

 _ o                         o    |    o       >    =            o)
  /\    - =   <             (|/   |   \|)               \       (| 
 | \                        /)    |    (\          \  _ /       / \
 
The game of life is a game of boomerangs.  Our thoughts, deeds and words
return to us sooner or later with astounding accuracy.


From normalperson at yhbt.net  Thu Jul  8 16:57:43 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 8 Jul 2010 13:57:43 -0700
Subject: Websocket Handshake 76
In-Reply-To: <20100708164149.37178aed@wigowyr>
References: <20100707172640.26fe0ce8@wigowyr>
	<20100707203848.GA21844@dcvr.yhbt.net>
	<20100708164149.37178aed@wigowyr>
Message-ID: <20100708205743.GB2991@dcvr.yhbt.net>

Niklas Hofer <niklas+rainbows at lanpartei.de> wrote:
> Am Wed, 7 Jul 2010 13:38:49 -0700
> schrieb Eric Wong <normalperson at yhbt.net>:
> 
> > I haven't gotten a chance to look into the new WebSocket updates, but
> > can't you just read the 8 bytes off env["rack.input"]?
> > 
> >   env["rack.input"].read(8)
> > 
> 
> I tried that without success, it does not give me anything (seems to
> be empty), even if I rewind it beforehand.

Ah, apparently -76 doesn't send Content-Length and that
screws things up (UGH!)

'env["hack.io"].read(8)' has a _chance_ of working if the
client delays sending the 8 bytes.

I think I'll need to change Rainbows! to not use readpartial and use
recv_nonblock with MSG_PEEK instead...

-- 
Eric Wong

From normalperson at yhbt.net  Thu Jul  8 18:07:19 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 8 Jul 2010 15:07:19 -0700
Subject: Websocket Handshake 76
In-Reply-To: <20100708205743.GB2991@dcvr.yhbt.net>
References: <20100707172640.26fe0ce8@wigowyr>
	<20100707203848.GA21844@dcvr.yhbt.net>
	<20100708164149.37178aed@wigowyr>
	<20100708205743.GB2991@dcvr.yhbt.net>
Message-ID: <20100708220719.GC7500@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> I think I'll need to change Rainbows! to not use readpartial and use
> recv_nonblock with MSG_PEEK instead...

It's too much trouble (and would hurt performance for non-WebSockets
stuff a bit).

Since we're not the only ones experiencing the issue, I think
we should wait until the next specification release and hope
they can fix things for us:

http://www.ietf.org/mail-archive/web/hybi/current/msg02149.html

-- 
Eric Wong

From normalperson at yhbt.net  Sat Jul 10 04:50:21 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 10 Jul 2010 08:50:21 +0000
Subject: [ANN] Rainbows! 0.95.0 - sendfile() support!
Message-ID: <20100710085021.GA14926@dcvr.yhbt.net>

Rainbows! is an HTTP server for sleepy Rack applications.  It is based on
Unicorn, but designed to handle applications that expect long
request/response times and/or slow clients.

* http://rainbows.rubyforge.org/
* rainbows-talk at rubyforge.org
* git://git.bogomips.org/rainbows.git

Changes:

In addition to the 1.9-only IO.copy_stream, the new sendfile
1.0.0 gem may optionally be used with most concurrency models
(even under 1.8).

See http://rainbows.rubyforge.org/Static_Files.html for more info

Other changes:

* 1.9 encoding bugfix for (Rev)FiberSpawn and FiberPool
* fixed potential rack.input corruption with Revactor
* ThreadPool graceful shutdown no longer blocks until timeout
* optional ServerToken middleware for to display Server: header
* Dependencies bumped to Rack 1.1+ and Unicorn 1.1.0+
* numerous internal cleanups, small bugfixes and speedups
* more concise website oriented at users

-- 
Eric Wong

From normalperson at yhbt.net  Sat Jul 10 06:12:35 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 10 Jul 2010 10:12:35 +0000
Subject: [ANN] Zbatery v0.3.0 - for newer Rainbows!
In-Reply-To: <20100710085021.GA14926@dcvr.yhbt.net>
References: <20100710085021.GA14926@dcvr.yhbt.net>
Message-ID: <20100710101235.GA16337@dcvr.yhbt.net>

Rainbows! v0.95.0 is more awesome than v0.94.0, so we've updated
ourselves to use it and be more awesome as well!

Zbatery is an HTTP server for Rack applications on systems that either
do not support fork(), or have no memory (nor need) to run the
master/worker model.  It is based on Rainbows! (which is based on
Unicorn (which is based on Mongrel)) and inherits parts of each.
Zbatery supports your choice of all the thread/fiber/event/actor-based
concurrency models and Rack middleware that Rainbows! supports (or will
ever support) in a single process.

* http://zbatery.bogomip.org/
* rainbows-talk at rubyforge.org
* git://git.bogomips.org/zbatery.git

-- 
Eric Wong

From normalperson at yhbt.net  Sat Jul 10 23:05:32 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 11 Jul 2010 03:05:32 +0000
Subject: [ANN] unicorn 1.1.1 - fixing cleanups gone bad :x
In-Reply-To: <20100708080457.GA2345@dcvr.yhbt.net>
References: <20100708080457.GA2345@dcvr.yhbt.net>
Message-ID: <20100711030532.GA22441@dcvr.yhbt.net>

Unicorn::TeeInput constant resolution for Unicorn::ClientError
got broken simplifying code for RDoc.  This affects users
of Rainbows! and Zbatery.

I've also made new minor releases for Rainbows! (0.95.1) and
Zbatery (0.3.1) users to depend on Unicorn 1.1.1

-- 
Eric Wong

From normalperson at yhbt.net  Thu Jul 15 02:03:38 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 15 Jul 2010 06:03:38 +0000
Subject: [RFC/PATCH] event_machine: lazily set async env keys
Message-ID: <20100715060338.GA2561@dcvr.yhbt.net>

This has the small likelyhood of breaking apps that
check via:
   env.include?("async.callback")

Or any of member?/has_key?/key?, as they're all the same method.

>From all the async examples I see, I just see apps just
use env["async.callback"].

Worth it?

>From 40ef059dfc99c7daad1b1829713727b86c8fc9a0 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson at yhbt.net>
Date: Thu, 15 Jul 2010 05:48:29 +0000
Subject: [PATCH] event_machine: lazily set async env keys

This is a micro-optimization when running a 'hello world' benchmark and
also reduces the strength of a memory leak under 1.9.2-rc2:

  http://redmine.ruby-lang.org/issues/show/3466
---
 lib/rainbows/ev_core.rb       |    1 -
 lib/rainbows/event_machine.rb |   17 ++++++++++++-----
 lib/rainbows/rev/client.rb    |    1 +
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/lib/rainbows/ev_core.rb b/lib/rainbows/ev_core.rb
index 5ca693b..357042b 100644
--- a/lib/rainbows/ev_core.rb
+++ b/lib/rainbows/ev_core.rb
@@ -16,7 +16,6 @@ module Rainbows
 
     def post_init
       @remote_addr = Rainbows.addr(@_io)
-      @env = {}
       @hp = HttpParser.new
       @state = :headers # [ :body [ :trailers ] ] :app_call :close
       @buf = ""
diff --git a/lib/rainbows/event_machine.rb b/lib/rainbows/event_machine.rb
index 173340e..14da118 100644
--- a/lib/rainbows/event_machine.rb
+++ b/lib/rainbows/event_machine.rb
@@ -54,6 +54,17 @@ module Rainbows
       G = Rainbows::G
 
       def initialize(io)
+        @env = Hash.new do |hash,key|
+          case key
+          when ASYNC_CALLBACK
+            hash[ASYNC_CALLBACK] = method(:em_write_response)
+          when ASYNC_CLOSE
+            # we're not sure if anybody uses this, but Thin sets it, too
+            hash[ASYNC_CLOSE] = EM::DefaultDeferrable.new
+          else
+            nil
+          end
+        end
         @_io = io
         @body = nil
       end
@@ -71,10 +82,6 @@ module Rainbows
         begin
           @env[RACK_INPUT] = @input
           @env[REMOTE_ADDR] = @remote_addr
-          @env[ASYNC_CALLBACK] = method(:em_write_response)
-
-          # we're not sure if anybody uses this, but Thin sets it, too
-          @env[ASYNC_CLOSE] = EM::DefaultDeferrable.new
 
           response = catch(:async) { APP.call(@env.update(RACK_DEFAULTS)) }
 
@@ -143,7 +150,7 @@ module Rainbows
       end
 
       def unbind
-        async_close = @env[ASYNC_CLOSE] and async_close.succeed
+        @env.include?(ASYNC_CLOSE) and @env[ASYNC_CLOSE].succeed
         @body.respond_to?(:fail) and @body.fail
         @_io.close
       end
diff --git a/lib/rainbows/rev/client.rb b/lib/rainbows/rev/client.rb
index d08992b..0df7415 100644
--- a/lib/rainbows/rev/client.rb
+++ b/lib/rainbows/rev/client.rb
@@ -15,6 +15,7 @@ module Rainbows
         CONN[self] = false
         super(io)
         post_init
+        @env = {}
         @deferred_bodies = [] # for (fast) regular files only
       end
 
-- 
Eric Wong

From jftucker at gmail.com  Thu Jul 15 10:22:29 2010
From: jftucker at gmail.com (James Tucker)
Date: Thu, 15 Jul 2010 15:22:29 +0100
Subject: [RFC/PATCH] event_machine: lazily set async env keys
In-Reply-To: <20100715060338.GA2561@dcvr.yhbt.net>
References: <20100715060338.GA2561@dcvr.yhbt.net>
Message-ID: <DC95175B-4AD7-452C-9F81-F87F922B9A85@gmail.com>

Sorry for the top post, trying to be quick...

Just regarding the async close, it's used primarily when the client disconnects so that you can stop asynchronous operations. It's quite important from a resource standpoint.

Why don't you just use a lambda instead of a method?

lambda { |*args| em_write_response(*args) }

That'd avoid the leak, and provide nearly the same performance profile. In fact on 1.9, lambdas are pretty damn quick.

On 15 Jul 2010, at 07:03, Eric Wong wrote:

> This has the small likelyhood of breaking apps that
> check via:
>  env.include?("async.callback")
> 
> Or any of member?/has_key?/key?, as they're all the same method.
> 
>> From all the async examples I see, I just see apps just
> use env["async.callback"].
> 
> Worth it?
> 
>> From 40ef059dfc99c7daad1b1829713727b86c8fc9a0 Mon Sep 17 00:00:00 2001
> From: Eric Wong <normalperson at yhbt.net>
> Date: Thu, 15 Jul 2010 05:48:29 +0000
> Subject: [PATCH] event_machine: lazily set async env keys
> 
> This is a micro-optimization when running a 'hello world' benchmark and
> also reduces the strength of a memory leak under 1.9.2-rc2:
> 
> http://redmine.ruby-lang.org/issues/show/3466
> ---
> lib/rainbows/ev_core.rb       |    1 -
> lib/rainbows/event_machine.rb |   17 ++++++++++++-----
> lib/rainbows/rev/client.rb    |    1 +
> 3 files changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/rainbows/ev_core.rb b/lib/rainbows/ev_core.rb
> index 5ca693b..357042b 100644
> --- a/lib/rainbows/ev_core.rb
> +++ b/lib/rainbows/ev_core.rb
> @@ -16,7 +16,6 @@ module Rainbows
> 
>    def post_init
>      @remote_addr = Rainbows.addr(@_io)
> -      @env = {}
>      @hp = HttpParser.new
>      @state = :headers # [ :body [ :trailers ] ] :app_call :close
>      @buf = ""
> diff --git a/lib/rainbows/event_machine.rb b/lib/rainbows/event_machine.rb
> index 173340e..14da118 100644
> --- a/lib/rainbows/event_machine.rb
> +++ b/lib/rainbows/event_machine.rb
> @@ -54,6 +54,17 @@ module Rainbows
>      G = Rainbows::G
> 
>      def initialize(io)
> +        @env = Hash.new do |hash,key|
> +          case key
> +          when ASYNC_CALLBACK
> +            hash[ASYNC_CALLBACK] = method(:em_write_response)
> +          when ASYNC_CLOSE
> +            # we're not sure if anybody uses this, but Thin sets it, too
> +            hash[ASYNC_CLOSE] = EM::DefaultDeferrable.new
> +          else
> +            nil
> +          end
> +        end
>        @_io = io
>        @body = nil
>      end
> @@ -71,10 +82,6 @@ module Rainbows
>        begin
>          @env[RACK_INPUT] = @input
>          @env[REMOTE_ADDR] = @remote_addr
> -          @env[ASYNC_CALLBACK] = method(:em_write_response)
> -
> -          # we're not sure if anybody uses this, but Thin sets it, too
> -          @env[ASYNC_CLOSE] = EM::DefaultDeferrable.new
> 
>          response = catch(:async) { APP.call(@env.update(RACK_DEFAULTS)) }
> 
> @@ -143,7 +150,7 @@ module Rainbows
>      end
> 
>      def unbind
> -        async_close = @env[ASYNC_CLOSE] and async_close.succeed
> +        @env.include?(ASYNC_CLOSE) and @env[ASYNC_CLOSE].succeed
>        @body.respond_to?(:fail) and @body.fail
>        @_io.close
>      end
> diff --git a/lib/rainbows/rev/client.rb b/lib/rainbows/rev/client.rb
> index d08992b..0df7415 100644
> --- a/lib/rainbows/rev/client.rb
> +++ b/lib/rainbows/rev/client.rb
> @@ -15,6 +15,7 @@ module Rainbows
>        CONN[self] = false
>        super(io)
>        post_init
> +        @env = {}
>        @deferred_bodies = [] # for (fast) regular files only
>      end
> 
> -- 
> Eric Wong
> _______________________________________________
> Rainbows! mailing list - rainbows-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying


From normalperson at yhbt.net  Thu Jul 15 17:05:30 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 15 Jul 2010 21:05:30 +0000
Subject: [RFC/PATCH] event_machine: lazily set async env keys
In-Reply-To: <DC95175B-4AD7-452C-9F81-F87F922B9A85@gmail.com>
References: <20100715060338.GA2561@dcvr.yhbt.net>
	<DC95175B-4AD7-452C-9F81-F87F922B9A85@gmail.com>
Message-ID: <20100715210530.GA30751@dcvr.yhbt.net>

James Tucker <jftucker at gmail.com> wrote:
> On 15 Jul 2010, at 07:03, Eric Wong wrote:
> 
> > This has the small likelyhood of breaking apps that
> > check via:
> >  env.include?("async.callback")
> > 
> > Or any of member?/has_key?/key?, as they're all the same method.

> Just regarding the async close, it's used primarily when the client
> disconnects so that you can stop asynchronous operations. It's quite
> important from a resource standpoint.

OK, but the EM::DefaultDeferrable object is never touched (or
even instantiated), then there's no need to close it.

> Why don't you just use a lambda instead of a method?
> 
> lambda { |*args| em_write_response(*args) }
>
> That'd avoid the leak, and provide nearly the same performance
> profile. In fact on 1.9, lambdas are pretty damn quick.

Durr... I didn't think of that :x

Since 1.9.2 is in RC with few users and this bug has a fix (at
http://redmine.ruby-lang.org/issues/show/3466), we might as well leave
the code as-is for now and skip my proposed patch.  Any objections?

I try to avoid working around other projects' bugs (and just helping fix
them).  This is especially the case for things like 1.9.2 which is still
in the very early stages of adoption.

-- 
Eric Wong

From jftucker at gmail.com  Thu Jul 15 17:43:06 2010
From: jftucker at gmail.com (James Tucker)
Date: Thu, 15 Jul 2010 22:43:06 +0100
Subject: [RFC/PATCH] event_machine: lazily set async env keys
In-Reply-To: <20100715210530.GA30751@dcvr.yhbt.net>
References: <20100715060338.GA2561@dcvr.yhbt.net>
	<DC95175B-4AD7-452C-9F81-F87F922B9A85@gmail.com>
	<20100715210530.GA30751@dcvr.yhbt.net>
Message-ID: <AFF9D5AF-FAD0-48D9-907E-059E92077BA6@gmail.com>


On 15 Jul 2010, at 22:05, Eric Wong wrote:

> James Tucker <jftucker at gmail.com> wrote:
>> On 15 Jul 2010, at 07:03, Eric Wong wrote:
>> 
>>> This has the small likelyhood of breaking apps that
>>> check via:
>>> env.include?("async.callback")
>>> 
>>> Or any of member?/has_key?/key?, as they're all the same method.
> 
>> Just regarding the async close, it's used primarily when the client
>> disconnects so that you can stop asynchronous operations. It's quite
>> important from a resource standpoint.
> 
> OK, but the EM::DefaultDeferrable object is never touched (or
> even instantiated), then there's no need to close it.
> 
>> Why don't you just use a lambda instead of a method?
>> 
>> lambda { |*args| em_write_response(*args) }
>> 
>> That'd avoid the leak, and provide nearly the same performance
>> profile. In fact on 1.9, lambdas are pretty damn quick.
> 
> Durr... I didn't think of that :x
> 
> Since 1.9.2 is in RC with few users and this bug has a fix (at
> http://redmine.ruby-lang.org/issues/show/3466), we might as well leave
> the code as-is for now and skip my proposed patch.  Any objections?
> 
> I try to avoid working around other projects' bugs (and just helping fix
> them).  This is especially the case for things like 1.9.2 which is still
> in the very early stages of adoption.

I have a similar patchset i'm not putting in for Thin. Also, the EM adjustment I made merely reduces the impact, and also increases performance:

http://github.com/eventmachine/eventmachine/commit/60b6472da952c7cdc59f093f93678dbd1739ab0a


From contact at famouswhy.com  Fri Jul 16 09:12:29 2010
From: contact at famouswhy.com (contact at famouswhy.com)
Date: Fri, 16 Jul 2010 08:12:29 -0500 (CDT)
Subject: Rainbows! has been granted the Famous Software Award -
	Download.FamousWhy.com
Message-ID: <20100716131229.E24D4310E93@mail.famouswhy.com>

Hello,

Congratulations!

Your product "Rainbows! (http://download.famouswhy.com/rainbows_/)" has been granted the "Famous Software Award" by Download.FamousWhy.com.  

The Famous Software Award has been initiated by Download.FamousWhy.com to recognize "Famous Software", which come up with innovative and efficient ways to reflect the best relationship with users assuring their satisfaction.

More information about our "Famous Software Award" is available on this page:

http://download.famouswhy.com/Awards/Famous-Software_3.html

We really hope that you will consider placing a banner with a link from your website to the software page at Download.FamousWhy.com because if you do it, visitors could come straight to the page and also discover the award which will give higher importance, confidence and value to your software and to all the services you're offering. They can also vote for it in order to keep a high position, a better exposure in our listings pages from the main page, categories, sub-categories and tops.

Below is the HTML code, you can copy and paste it on your page:

-------------------------
<a href="http://download.famouswhy.com/rainbows_/" target="_blank"><img src="http://download.famouswhy.com/awards/Famous_Software_Award_Logo.png"
alt="Rainbows!" style="border:0"></a>
-------------------------

IMPORTANT!

If you decide to place a link pointing to your software page at Download.FamousWhy.com, just let us know and our editors will write reviews (http://download.famouswhy.com/portable_irfanview/), create polls, articles (http://articles.famouswhy.com/first_impressions_on_east-tec_eraser_2010/), tutorials (http://forum.famouswhy.com/index.php?showtopic=19590), questions, famous lists for your software and will take you a "famous interview" (http://download.famouswhy.com/publisher/irfan_skiljan/) about your website, business or services which will significantly improve your popularity as a company and it can promote your software and website in front of thousands of people, outrunning your competitors. We proudly announce that everything mentioned above is FREE OF COST!

We can soon promote your software exposing it in our Featured Section of the website we're working on right now.

So proudly display a "Famous Software Award" badge with a link back to your software page!

Don't hesitate to contact us for more information.

Thanks -- and again, congratulations!

Sincerely,

The FamousWhy Software Editorial Team
http://Download.FamousWhy.com

----------------------------------------------
"Making your software famous has never been easier!"
----------------------------------------------

From jftucker at gmail.com  Fri Jul 16 10:33:17 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 16 Jul 2010 15:33:17 +0100
Subject: Rainbows! has been granted the Famous Software Award -
	Download.FamousWhy.com
In-Reply-To: <20100716131229.E24D4310E93@mail.famouswhy.com>
References: <20100716131229.E24D4310E93@mail.famouswhy.com>
Message-ID: <3108E017-FE03-4771-99C4-C72FB09AABEF@gmail.com>

This site is full of complete and utter filth, can we ban them from posting in order to help people not get infected by their nefarious crap.

On 16 Jul 2010, at 14:12, contact at famouswhy.com wrote:

> Hello,
> 
> Congratulations!
> 
> Your product "Rainbows! (http://download.famouswhy.com/rainbows_/)" has been granted the "Famous Software Award" by Download.FamousWhy.com.  
> 
> The Famous Software Award has been initiated by Download.FamousWhy.com to recognize "Famous Software", which come up with innovative and efficient ways to reflect the best relationship with users assuring their satisfaction.
> 
> More information about our "Famous Software Award" is available on this page:
> 
> http://download.famouswhy.com/Awards/Famous-Software_3.html
> 
> We really hope that you will consider placing a banner with a link from your website to the software page at Download.FamousWhy.com because if you do it, visitors could come straight to the page and also discover the award which will give higher importance, confidence and value to your software and to all the services you're offering. They can also vote for it in order to keep a high position, a better exposure in our listings pages from the main page, categories, sub-categories and tops.
> 
> Below is the HTML code, you can copy and paste it on your page:
> 
> -------------------------
> <a href="http://download.famouswhy.com/rainbows_/" target="_blank"><img src="http://download.famouswhy.com/awards/Famous_Software_Award_Logo.png"
> alt="Rainbows!" style="border:0"></a>
> -------------------------
> 
> IMPORTANT!
> 
> If you decide to place a link pointing to your software page at Download.FamousWhy.com, just let us know and our editors will write reviews (http://download.famouswhy.com/portable_irfanview/), create polls, articles (http://articles.famouswhy.com/first_impressions_on_east-tec_eraser_2010/), tutorials (http://forum.famouswhy.com/index.php?showtopic=19590), questions, famous lists for your software and will take you a "famous interview" (http://download.famouswhy.com/publisher/irfan_skiljan/) about your website, business or services which will significantly improve your popularity as a company and it can promote your software and website in front of thousands of people, outrunning your competitors. We proudly announce that everything mentioned above is FREE OF COST!
> 
> We can soon promote your software exposing it in our Featured Section of the website we're working on right now.
> 
> So proudly display a "Famous Software Award" badge with a link back to your software page!
> 
> Don't hesitate to contact us for more information.
> 
> Thanks -- and again, congratulations!
> 
> Sincerely,
> 
> The FamousWhy Software Editorial Team
> http://Download.FamousWhy.com
> 
> ----------------------------------------------
> "Making your software famous has never been easier!"
> ----------------------------------------------
> _______________________________________________
> Rainbows! mailing list - rainbows-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying


From normalperson at yhbt.net  Fri Jul 16 14:38:19 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 16 Jul 2010 18:38:19 +0000
Subject: Rainbows! has been granted the Famous Software Award -
	Download.FamousWhy.com
In-Reply-To: <3108E017-FE03-4771-99C4-C72FB09AABEF@gmail.com>
References: <20100716131229.E24D4310E93@mail.famouswhy.com>
	<3108E017-FE03-4771-99C4-C72FB09AABEF@gmail.com>
Message-ID: <20100716183818.GA8037@dcvr.yhbt.net>

James Tucker <jftucker at gmail.com> wrote:
> This site is full of complete and utter filth, can we ban them from
> posting in order to help people not get infected by their nefarious
> crap.

Should be filtered from now on. I wonder if it's possible to remove the
listing entirely from their site, has anybody had success on this front?

Also in the case of spam like this, don't even bother quoting, subject (or
even just Message-ID) is fine.

-- 
Eric Wong

From normalperson at yhbt.net  Tue Jul 20 02:18:03 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 19 Jul 2010 23:18:03 -0700
Subject: range requests and multipart responses
Message-ID: <20100720061803.GA8037@dcvr.yhbt.net>

Hi all,

Does anybody have real-world use cases of clients using Range: requests
with multiple comma-delimited byte ranges (and thus expecting multipart
responses)?  If not, I'm not going to bloat Rainbows! with it for now[1].

While being able to specify a single range is very useful for resuming
failed downloads and for things who want to "peek" at magic patterns
before requesting the rest of a file, I can't think of good use cases
for having to deal with multipart responses.

Even if you were writing a FUSE-based filesystem over HTTP, it wouldn't
even be useful for implementing preadv(2) since you can only specify a
single offset there.

Maybe if you mmap() a FUSE-ed file and two threads access the same file
in different parts at the *exact*same*time* the FUSE layer could be
smart enough to make a single HTTP request instead of two? :)


[1] - For the performance-minded, it's also tough to implement multipart
      responses efficiently using any sendfile() implementation.
      Our TCP_CORK support is far from optimal under Linux right now,
      and not using TCP_CORK would be even less efficient with extra
      multipart headers.  AFAIK, sendfilev() isn't available outside of
      Solaris, either.

-- 
Eric Wong

From jftucker at gmail.com  Tue Jul 20 05:21:15 2010
From: jftucker at gmail.com (James Tucker)
Date: Tue, 20 Jul 2010 10:21:15 +0100
Subject: range requests and multipart responses
In-Reply-To: <20100720061803.GA8037@dcvr.yhbt.net>
References: <20100720061803.GA8037@dcvr.yhbt.net>
Message-ID: <71E4CB4E-365A-4A6B-85EA-9C24415E1234@gmail.com>


On 20 Jul 2010, at 07:18, Eric Wong wrote:

> Hi all,
> 
> Does anybody have real-world use cases of clients using Range: requests
> with multiple comma-delimited byte ranges (and thus expecting multipart
> responses)?  If not, I'm not going to bloat Rainbows! with it for now[1].
> 
> While being able to specify a single range is very useful for resuming
> failed downloads and for things who want to "peek" at magic patterns
> before requesting the rest of a file, I can't think of good use cases
> for having to deal with multipart responses.
> 
> Even if you were writing a FUSE-based filesystem over HTTP, it wouldn't
> even be useful for implementing preadv(2) since you can only specify a
> single offset there.
> 
> Maybe if you mmap() a FUSE-ed file and two threads access the same file
> in different parts at the *exact*same*time* the FUSE layer could be
> smart enough to make a single HTTP request instead of two? :)
> 
> 
> [1] - For the performance-minded, it's also tough to implement multipart
>      responses efficiently using any sendfile() implementation.
>      Our TCP_CORK support is far from optimal under Linux right now,
>      and not using TCP_CORK would be even less efficient with extra
>      multipart headers.  AFAIK, sendfilev() isn't available outside of
>      Solaris, either.

Does cork even help in real world use cases?

> 
> -- 
> Eric Wong
> _______________________________________________
> Rainbows! mailing list - rainbows-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying


From normalperson at yhbt.net  Tue Jul 20 14:54:59 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 20 Jul 2010 11:54:59 -0700
Subject: range requests and multipart responses
In-Reply-To: <71E4CB4E-365A-4A6B-85EA-9C24415E1234@gmail.com>
References: <20100720061803.GA8037@dcvr.yhbt.net>
	<71E4CB4E-365A-4A6B-85EA-9C24415E1234@gmail.com>
Message-ID: <20100720185459.GA2732@dcvr.yhbt.net>

James Tucker <jftucker at gmail.com> wrote:
> On 20 Jul 2010, at 07:18, Eric Wong wrote:
> > [1] - For the performance-minded, it's also tough to implement multipart
> >      responses efficiently using any sendfile() implementation.
> >      Our TCP_CORK support is far from optimal under Linux right now,
> >      and not using TCP_CORK would be even less efficient with extra
> >      multipart headers.  AFAIK, sendfilev() isn't available outside of
> >      Solaris, either.
> 
> Does cork even help in real world use cases?

Heh, good question :)

I've only seen it help in microbenchmarks and analyzing tcpdump output.
I've never bothered checking in Ruby apps (never though it'd be worth my
time, even), but I don't expect it to be worth the effort.  Maybe
somebody else will care enough...

However, I've seen corking hurt badly for things like chat apps and
anything with bidirectional small messages.  It's impossible for the
server to reliably tell what type of traffic to expect without the app
stepping in to tell it to uncork at certain points.

-- 
Eric Wong

From maccman at gmail.com  Thu Jul 29 16:42:33 2010
From: maccman at gmail.com (Alex MacCaw)
Date: Thu, 29 Jul 2010 13:42:33 -0700
Subject: Error with Rails 3
Message-ID: <5153C416-A35C-48F4-9B8D-D19A81860499@gmail.com>

/Users/Alex/.bundler/ruby/1.9.1/rails-d69949e/activesupport/lib/active_support/dependencies.rb:219:in `require': no such file to load -- rainbows/response/body (LoadError)

From normalperson at yhbt.net  Thu Jul 29 16:52:16 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 29 Jul 2010 13:52:16 -0700
Subject: Error with Rails 3
In-Reply-To: <5153C416-A35C-48F4-9B8D-D19A81860499@gmail.com>
References: <5153C416-A35C-48F4-9B8D-D19A81860499@gmail.com>
Message-ID: <20100729205216.GA28995@dcvr.yhbt.net>

Alex MacCaw <maccman at gmail.com> wrote:
> /Users/Alex/.bundler/ruby/1.9.1/rails-d69949e/activesupport/lib/active_support/dependencies.rb:219:in
> `require': no such file to load -- rainbows/response/body (LoadError)

Hi Alex, can you try bundling the "rainbows" gem with your app?

All the info for using Unicorn with Bundler and Isolate should apply to
Rainbows! as well:
http://unicorn.bogomips.org/Sandbox.html

-- 
Eric Wong