From normalperson at yhbt.net  Wed Dec  2 04:12:36 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 2 Dec 2009 09:12:36 +0000
Subject: [ANN] Rainbows! 0.8.0
Message-ID: <20091202091235.GA11735@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.  For Rack applications not
heavily bound by slow external network dependencies, consider Unicorn
instead as it simpler and easier to debug.

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

Changes:

This release fixes a memory leak in our existing Revactor
concurrency model.  A new RevThreadPool concurrency model has
been added as well as small cleaups to exit handling in workers.

-- 
Eric Wong

From noreply at vk.com  Thu Dec  3 04:23:56 2009
From: noreply at vk.com (VK)
Date: Thu, 3 Dec 2009 12:23:56 +0300
Subject: Anton StiXy Kozlov has added you as a friend on the website VK.com
Message-ID: <632ba7e6ef730815bb5aa473be431c0c@localhost.localdomain>

Hello,

Anton StiXy Kozlov has added you as a friend on the website VK.com

You can log in and view your friends` pages using your email and automatically created password: iXJmFFo2

VK.com is a website that helps dozens of millions of people find their old friends, share photos and events and always stay in touch.

To log in, please follow this link:
http://vk.com/login.php?regemail=rainbows-talk at rubyforge.org#iXJmFFo2

You can change your password in Settings.

Attention: If you ignore this invitation, your registration will not be activated.

Good luck!



From insinium at gmail.com  Mon Dec  7 11:40:15 2009
From: insinium at gmail.com (Alexander)
Date: Mon, 7 Dec 2009 19:40:15 +0300
Subject: Long Polling
Message-ID: <fc2a0ebf0912070840r5ffec0d2r5eb72419ae810f21@mail.gmail.com>

Please, could anybody explain how to create simple long polling app
with rainbows?

From normalperson at yhbt.net  Mon Dec  7 15:02:34 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 7 Dec 2009 12:02:34 -0800
Subject: Long Polling
In-Reply-To: <fc2a0ebf0912070840r5ffec0d2r5eb72419ae810f21@mail.gmail.com>
References: <fc2a0ebf0912070840r5ffec0d2r5eb72419ae810f21@mail.gmail.com>
Message-ID: <20091207200234.GA26894@dcvr.yhbt.net>

Alexander <insinium at gmail.com> wrote:
> Please, could anybody explain how to create simple long polling app
> with rainbows?

Hi Alexander,

I'm not sure if anybody has actually written one for Rainbows!, but I
think they usually include sleeping or using async.callback like
async_sinatra[1].

For the concurrency models that appear synchronous, you can check out
t/sleep.ru in the test cases for sleep examples:

  (case env['rainbows.model']
  when :FiberPool, :FiberSpawn
    Rainbows::Fiber
  when :Revactor
    Actor
  else # :ThreadPool, :ThreadSpawn
    Kernel
  end).sleep(nr)

I may put that logic into a env["async.sleep"] callback in places where
env["async.callback"] is not available so the synchronous-looking
concurrency models can all share the same code.

If you're using EventMachine, NeverBlock (and in future versions: Rev,
RevThreadSpawn, RevThreadPool, EventMachineDefer,
EventMachineThreadSpawn), you can use "async.callback" or just use
async_synatra which uses "async.callback" internally.

[1] http://github.com/raggi/async_sinatra

-- 
Eric Wong

From normalperson at yhbt.net  Tue Dec  8 04:06:56 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 8 Dec 2009 09:06:56 +0000
Subject: RFC: env["async.sleep"] callback
Message-ID: <20091208090656.GA23679@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> For the concurrency models that appear synchronous, you can check out
> t/sleep.ru in the test cases for sleep examples:
> 
>   (case env['rainbows.model']
>   when :FiberPool, :FiberSpawn
>     Rainbows::Fiber
>   when :Revactor
>     Actor
>   else # :ThreadPool, :ThreadSpawn
>     Kernel
>   end).sleep(nr)
> 
> I may put that logic into a env["async.sleep"] callback in places where
> env["async.callback"] is not available so the synchronous-looking
> concurrency models can all share the same code.

Does anybody have any more thoughts (for or against) on this issue?

Most of the "sleepy" apps I've seen are actually unavoidably sleepy
because they're waiting on an external API call, and not just because
the app feels like sleeping...

-- 
Eric Wong

From insinium at gmail.com  Tue Dec  8 09:26:50 2009
From: insinium at gmail.com (Alexander)
Date: Tue, 8 Dec 2009 17:26:50 +0300
Subject: Long Polling
In-Reply-To: <20091207200234.GA26894@dcvr.yhbt.net>
References: <fc2a0ebf0912070840r5ffec0d2r5eb72419ae810f21@mail.gmail.com>
	<20091207200234.GA26894@dcvr.yhbt.net>
Message-ID: <fc2a0ebf0912080626k759d0941h67541436e1723f34@mail.gmail.com>

Hello Eric!
Thank You very much!
After some unsuccessful attempt to construct it,
I mean, that finaly, a got worked class.

So, if intresting, you can look it

require 'sinatra/async'

class LongPollingServlet < Sinatra::Base
  register Sinatra::Async

  enable :show_exceptions

  def initialize
    @queue = []
  end

  aget '/' do
    @queue << EM.Callback { |message| body message }
  end

  get '/pull/:message' do |message|
    obj = @queue.shift
    obj.call message if obj
  end

end

run LongPollingServlet.new


Thanks for explains,
YR,
Alexander.

2009/12/7 Eric Wong <normalperson at yhbt.net>
>
> Alexander <insinium at gmail.com> wrote:
> > Please, could anybody explain how to create simple long polling app
> > with rainbows?
>
> Hi Alexander,
>
> I'm not sure if anybody has actually written one for Rainbows!, but I
> think they usually include sleeping or using async.callback like
> async_sinatra[1].
>
> For the concurrency models that appear synchronous, you can check out
> t/sleep.ru in the test cases for sleep examples:
>
> ?(case env['rainbows.model']
> ?when :FiberPool, :FiberSpawn
> ? ?Rainbows::Fiber
> ?when :Revactor
> ? ?Actor
> ?else # :ThreadPool, :ThreadSpawn
> ? ?Kernel
> ?end).sleep(nr)
>
> I may put that logic into a env["async.sleep"] callback in places where
> env["async.callback"] is not available so the synchronous-looking
> concurrency models can all share the same code.
>
> If you're using EventMachine, NeverBlock (and in future versions: Rev,
> RevThreadSpawn, RevThreadPool, EventMachineDefer,
> EventMachineThreadSpawn), you can use "async.callback" or just use
> async_synatra which uses "async.callback" internally.
>
> [1] http://github.com/raggi/async_sinatra
>
> --
> 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 Dec 10 04:19:19 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 10 Dec 2009 09:19:19 +0000
Subject: [ANN] Zbatery - Rack HTTP server without a fork stuck in it
Message-ID: <20091210091919.GB24828@dcvr.yhbt.net>

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.

Zbatery will still exploit certain features of Unix for transparent
upgrades, log reopening, and graceful stops, but does not rely on them
for basic functionality.

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

== Features

* Designed for {Rack}[http://rack.rubyforge.org/], the standard for
  modern Ruby HTTP applications.

* Configuration files are compatible with Rainbows!, a superset
  of the Unicorn
  {DSL}[http://unicorn.bogomips.org/Unicorn/Configurator.html].

* Inherits all features and concurrency models Rainbows! supports
  (and ever will support): http://rainbows.rubyforge.org/Summary.html

* -Untested- Works under operating systems that don't support signals,
  pipe and fork().  Unicorn 0.95.2+ has rake-compiler support, so
  compiling the HTTP parser should be easier at least.

* -Untested- HTML 5 Web Sockets support

This project may be temporary and may eventually have its name encoded
with uncrackable ROT13 encryption leaving you with no way to upgrade.

-- 
Eric Wong

From normalperson at yhbt.net  Thu Dec 10 18:32:36 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 10 Dec 2009 15:32:36 -0800
Subject: HTML5 WebSockets
In-Reply-To: <20091124192430.GA4965@dcvr.yhbt.net>
References: <20091124192430.GA4965@dcvr.yhbt.net>
Message-ID: <20091210233236.GA23608@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> Hi all,
> 
> The Revactor/ThreadSpawn/ThreadPool concurrency models *should* already
> support HTML5 WebSockets out-of-the-box right now with the respective
> TeeInput (streaming "rack.input" support).  You'll probably want to make
> sure the Rack::Chunked middleware is loaded for anything you run, but
> other than that everything should work provided you have a working
> client-side implementation...
> 
> I'm terrible at doing anything interactive on web browsers[1] and I
> don't think any current browsers out there support WebSockets natively,
> but there are ways to mimic it with JS libraries it seems.
> 
> If anybody can code anything up and put up a demo, that would be great.

The new version of Chrome supports Web Sockets, so yes, I'd like to
confirm that our streaming "rack.input" support works with Web Sockets.

As always, I'm trying to avoid GUI development myself, but may end
up having to like I did with upr (http://upr.bogomips.org/) and
gaining more gray hairs in the process :<

> I'll get around to adding a Fiber-based concurrency model which should
> work with TeeInput, too.

FiberSpawn and FiberPool have been added since and both seem to work
great.

Unconfirmed, but the IO.select()-based scheduler for these should also
give these a slight advantage when balancing between multiple worker
processes.

-- 
Eric Wong

From normalperson at yhbt.net  Fri Dec 11 02:48:43 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 10 Dec 2009 23:48:43 -0800
Subject: HTML5 WebSockets
In-Reply-To: <20091210233236.GA23608@dcvr.yhbt.net>
References: <20091124192430.GA4965@dcvr.yhbt.net>
	<20091210233236.GA23608@dcvr.yhbt.net>
Message-ID: <20091211074843.GA28185@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> The new version of Chrome supports Web Sockets, so yes, I'd like to
> confirm that our streaming "rack.input" support works with Web Sockets.

Reading the RFC[1] and the pywebsocket[2], it looks like
Transfer-Encoding: chunked is not used at all.  This means we'll have to
add an extension env instead of using "rack.input".

The good part about this is that we're no longer constrained by the
rewindable stream requirement, so there's no longer any need for
TeeInput nor filesystem I/O...

[1] - http://tools.ietf.org/id/draft-hixie-thewebsocketprotocol
[2] - http://code.google.com/p/pywebsocket/

> As always, I'm trying to avoid GUI development myself, but may end

Well, pywebsocket includes a command-line example client, so I'll just
develop with that and not have to deal with getting Chrome to run.

-- 
Eric Wong

From normalperson at yhbt.net  Fri Dec 11 06:50:41 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 11 Dec 2009 03:50:41 -0800
Subject: [ANN] LMGTWTY: Web Sockets Library for Rack+Rainbows!
Message-ID: <20091211115041.GA14610@dcvr.yhbt.net>

LMGTWTY is a Rainbows! (and Zbatery) Rack library for Web Sockets.  It
uses unofficial extensions in rainbows.git for Rack which are subject to
change, but it appears to work well enough for the echo_client.py
example shipped with pywebsocket.

It has not been tested against normal web browsers, though there's
no reason it shouldn't work.

It currently depends on the git version of Rainbows.

http://git.bogomips.org/cgit/lmgtwty.git
http://git.bogomips.org/cgit/rainbows.git

There are no releases yet, just grab from git
(install the wonderful "iobuffer" gem, too).

The API is subject to change (like Web Sockets itself (I think)).  This
was done completely on a whim tonight, with no thought or planning
beforehand.  So I can't say I'm completely happy with the API.

At least I believe I finally understand Ruby 1.9 encodings
after writing Lmgtwty::IO (having read and reread article after
article on it over the past few years)...

Mailing list is here: lmgtwty at librelist.com
Just send and email and follow instructions to subscribe.

-- 
Eric Wong

From normalperson at yhbt.net  Fri Dec 11 06:53:48 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 11 Dec 2009 03:53:48 -0800
Subject: [ANN] LMGTWTY: Web Sockets Library for Rack+Rainbows!
In-Reply-To: <20091211115041.GA14610@dcvr.yhbt.net>
References: <20091211115041.GA14610@dcvr.yhbt.net>
Message-ID: <20091211115348.GB14610@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> http://git.bogomips.org/cgit/lmgtwty.git
> http://git.bogomips.org/cgit/rainbows.git
> 
> There are no releases yet, just grab from git
> (install the wonderful "iobuffer" gem, too).

One more thing, for both of them, if you have RubyGems 1.3.5,
"make install-gem" works (or "make gem" and then manually
installing the file).

Of course "make install" works too if you're not worried
about uninstalling.

-- 
Eric Wong

From normalperson at yhbt.net  Fri Dec 11 06:59:05 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 11 Dec 2009 03:59:05 -0800
Subject: [PATCH] env["hack.io"] for Fiber*, Revactor, Thread* models
In-Reply-To: <20091211115348.GB14610@dcvr.yhbt.net>
References: <20091211115041.GA14610@dcvr.yhbt.net>
	<20091211115348.GB14610@dcvr.yhbt.net>
Message-ID: <20091211115905.GA15621@dcvr.yhbt.net>

This exposes a client IO object directly to the underlying
application.
---

  In case you already have an installation and just want to patch that,
  this is the patch I made for Rainbows! that exposes the ability to
  be used with LMGTWTY

 lib/rainbows/base.rb       |    1 +
 lib/rainbows/const.rb      |    6 ++++++
 lib/rainbows/fiber/base.rb |    1 +
 lib/rainbows/revactor.rb   |    1 +
 4 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/lib/rainbows/base.rb b/lib/rainbows/base.rb
index 424b43b..a735b82 100644
--- a/lib/rainbows/base.rb
+++ b/lib/rainbows/base.rb
@@ -43,6 +43,7 @@ module Rainbows
           buf << client.readpartial(CHUNK_SIZE)
         end
 
+        env[CLIENT_IO] = client
         env[RACK_INPUT] = 0 == hp.content_length ?
                  HttpRequest::NULL_IO :
                  Unicorn::TeeInput.new(client, env, hp, buf)
diff --git a/lib/rainbows/const.rb b/lib/rainbows/const.rb
index 69e58aa..900c9d9 100644
--- a/lib/rainbows/const.rb
+++ b/lib/rainbows/const.rb
@@ -19,5 +19,11 @@ module Rainbows
     CONN_ALIVE = "Connection: keep-alive\r\n"
     LOCALHOST = "127.0.0.1"
 
+    # client IO object that supports reading and writing directly
+    # without filtering it through the HTTP chunk parser.
+    # Maybe we can get this renamed to "rack.io" if it becomes part
+    # of the official spec, but for now it is "hack.io"
+    CLIENT_IO = "hack.io".freeze
+
   end
 end
diff --git a/lib/rainbows/fiber/base.rb b/lib/rainbows/fiber/base.rb
index 129448c..995b4af 100644
--- a/lib/rainbows/fiber/base.rb
+++ b/lib/rainbows/fiber/base.rb
@@ -82,6 +82,7 @@ module Rainbows
             buf << (client.read_timeout or return)
           end
 
+          env[CLIENT_IO] = client
           env[RACK_INPUT] = 0 == hp.content_length ?
                     HttpRequest::NULL_IO : TeeInput.new(client, env, hp, buf)
           env[REMOTE_ADDR] = remote_addr
diff --git a/lib/rainbows/revactor.rb b/lib/rainbows/revactor.rb
index b647d48..ff0e429 100644
--- a/lib/rainbows/revactor.rb
+++ b/lib/rainbows/revactor.rb
@@ -49,6 +49,7 @@ module Rainbows
           buf << client.read(*rd_args)
         end
 
+        env[Const::CLIENT_IO] = client
         env[Const::RACK_INPUT] = 0 == hp.content_length ?
                  HttpRequest::NULL_IO :
                  Rainbows::Revactor::TeeInput.new(client, env, hp, buf)
-- 
Eric Wong

From normalperson at yhbt.net  Fri Dec 11 14:44:05 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 11 Dec 2009 19:44:05 +0000
Subject: Web Sockets echo server demo!
Message-ID: <20091211194405.GC2121@dcvr.yhbt.net>

Just grab the echo_client.py from pywebsocket here:

  http://pywebsocket.googlecode.com/svn/trunk/src/example/echo_client.py
  (tested with r139)

And run:
$ python echo_client.py -p 9999 -s yhbt.net
$ python echo_client.py -p 9999 -s yhbt.net -m "hello,world"
...

The demo is running Zbatery + Rainbows! v0.8.0-15-g42fbb5d + FiberSpawn
under Ruby 1.9.

-- 
Eric Wong

From 5-conceit at hisensecom.com  Sat Dec 12 21:31:13 2009
From: 5-conceit at hisensecom.com (Alana nadir)
Date: 13 Dec 2009 10:31:13 +0800
Subject: Yes I have dental and medical lists
Message-ID: <MAILSERVERXvpFVjCRG00000008@MailServer.nanshan-ag.com>




All data COMES (Excel format File fully exportable an unlimited usage license). 
WE ACCEPT ALL CREDIT CARDS Euro card cards, as well as other payment methods: 

Complete Physician Database 788,800 doctors available for direct mail 
Physician Email 48,500 (17,441Unique) Physician Fax Database 202,466 
First name* Last name* Title* Specialty* Address (city, state, zip, county)*Medical School 
Attended* Residency Training* Phone/Fax * Email* Website* Primary Specialty* Secondary Specialty* 
(PHYSICIANS DATABASE COMES SORTED BY STATE AND BY SPECIALTIES) 

==== Package: Cost this WK ONLY $395.00====
 
*****Also included are the 6 list below***** 
1= 7145 Hospitals*23,000 Administrators with Ph/fax and postal address. No emails (reg: $399) 
2= Licensed Clinic/Dentist 597,959 Total Records*6,494 Emails*6,000 Fax Numbers. (reg: $599) 
3= US Pharmaceutical Company 47,000 employees in high-ranking positions (reg: $299) 
   Executive's Directory Names and email addresses of 
4= Chiropractors*108,421 with phone, 3,414 emails and 6,553 fax numbers. (reg: $399) 
5= Acupuncture Database 23,988 records 1,826 emails (reg: $299) 
6= Alternative Medicine Clinics and Practitioners Database (reg: $699) 
   There are 1,141,602 total records with 29,320 emails and 38.935 fax numbers. 

If you order before This WK you get the Dentist lists listed below to: 
New for this Year: Database of Dentists <> in America <> (Regular price $390) 
192,003 Dentists with City, State, Zip* 189,050 Addresses* 191,033hone Numbers 
95,226 Fax #'s* 51,440 E-Mail Addresses 



+++++++Good until the end of this week+++++++
 
I can give you any one for $149 or for three $329.00 of the list below

Chiropractors<>Alternative Medicine<>Veterinarians<>Hospitals<>National Health Service Corp Clinics
<>Nursing Homes<> Pharmaceutical Companies<>Physical Therapists<>Acupuncturists<>Hotels 
Criminal Attorneys<>Real Estate Agents<>Massage Therapists<>Medical Equipment Suppliers 
Mental Health Counselors<>Visiting Nurses & RN's<>Optometrists<>Pharmaceutical Companies 
Psychologists<>Building Trades 

send and email to: Nellie at listmastersmd.nom.es

Good until the end of this week.










To be erased from our list please send an email to  rembox at listmastersmd.nom.es


From jftucker at gmail.com  Sun Dec 13 08:47:52 2009
From: jftucker at gmail.com (James Tucker)
Date: Sun, 13 Dec 2009 13:47:52 +0000
Subject: [PATCH] env["hack.io"] for Fiber*, Revactor, Thread* models
In-Reply-To: <20091211115905.GA15621@dcvr.yhbt.net>
References: <20091211115041.GA14610@dcvr.yhbt.net>
	<20091211115348.GB14610@dcvr.yhbt.net>
	<20091211115905.GA15621@dcvr.yhbt.net>
Message-ID: <D3B4FD37-50B9-4913-88E3-92C1B1877ED8@gmail.com>

Testing, all my mails to this ML seem to be getting rejected based on content type, seems Mail.app isn't sending plain, when I tell it to, or it doesn't like my S/MIME


On 11 Dec 2009, at 11:59, Eric Wong wrote:

> This exposes a client IO object directly to the underlying
> application.
> ---
> 
>  In case you already have an installation and just want to patch that,
>  this is the patch I made for Rainbows! that exposes the ability to
>  be used with LMGTWTY
> 
> lib/rainbows/base.rb       |    1 +
> lib/rainbows/const.rb      |    6 ++++++
> lib/rainbows/fiber/base.rb |    1 +
> lib/rainbows/revactor.rb   |    1 +
> 4 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/rainbows/base.rb b/lib/rainbows/base.rb
> index 424b43b..a735b82 100644
> --- a/lib/rainbows/base.rb
> +++ b/lib/rainbows/base.rb
> @@ -43,6 +43,7 @@ module Rainbows
>           buf << client.readpartial(CHUNK_SIZE)
>         end
> 
> +        env[CLIENT_IO] = client
>         env[RACK_INPUT] = 0 == hp.content_length ?
>                  HttpRequest::NULL_IO :
>                  Unicorn::TeeInput.new(client, env, hp, buf)
> diff --git a/lib/rainbows/const.rb b/lib/rainbows/const.rb
> index 69e58aa..900c9d9 100644
> --- a/lib/rainbows/const.rb
> +++ b/lib/rainbows/const.rb
> @@ -19,5 +19,11 @@ module Rainbows
>     CONN_ALIVE = "Connection: keep-alive\r\n"
>     LOCALHOST = "127.0.0.1"
> 
> +    # client IO object that supports reading and writing directly
> +    # without filtering it through the HTTP chunk parser.
> +    # Maybe we can get this renamed to "rack.io" if it becomes part
> +    # of the official spec, but for now it is "hack.io"
> +    CLIENT_IO = "hack.io".freeze
> +
>   end
> end
> diff --git a/lib/rainbows/fiber/base.rb b/lib/rainbows/fiber/base.rb
> index 129448c..995b4af 100644
> --- a/lib/rainbows/fiber/base.rb
> +++ b/lib/rainbows/fiber/base.rb
> @@ -82,6 +82,7 @@ module Rainbows
>             buf << (client.read_timeout or return)
>           end
> 
> +          env[CLIENT_IO] = client
>           env[RACK_INPUT] = 0 == hp.content_length ?
>                     HttpRequest::NULL_IO : TeeInput.new(client, env, hp, buf)
>           env[REMOTE_ADDR] = remote_addr
> diff --git a/lib/rainbows/revactor.rb b/lib/rainbows/revactor.rb
> index b647d48..ff0e429 100644
> --- a/lib/rainbows/revactor.rb
> +++ b/lib/rainbows/revactor.rb
> @@ -49,6 +49,7 @@ module Rainbows
>           buf << client.read(*rd_args)
>         end
> 
> +        env[Const::CLIENT_IO] = client
>         env[Const::RACK_INPUT] = 0 == hp.content_length ?
>                  HttpRequest::NULL_IO :
>                  Rainbows::Revactor::TeeInput.new(client, env, hp, buf)
> -- 
> 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  Sun Dec 13 14:45:53 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 13 Dec 2009 19:45:53 +0000
Subject: [PATCH] env["hack.io"] for Fiber*, Revactor, Thread* models
In-Reply-To: <D3B4FD37-50B9-4913-88E3-92C1B1877ED8@gmail.com>
References: <20091211115041.GA14610@dcvr.yhbt.net>
	<20091211115348.GB14610@dcvr.yhbt.net>
	<20091211115905.GA15621@dcvr.yhbt.net>
	<D3B4FD37-50B9-4913-88E3-92C1B1877ED8@gmail.com>
Message-ID: <20091213194553.GC19572@dcvr.yhbt.net>

James Tucker <jftucker at gmail.com> wrote:
> Testing, all my mails to this ML seem to be getting rejected based on
> content type, seems Mail.app isn't sending plain, when I tell it to,
> or it doesn't like my S/MIME

Hi James,

Only text/plain is allowed at the moment.  And looking at your S/MIME
signatures on rack-devel, they're humongous compared to the size of the
message.

-- 
Eric Wong

From normalperson at yhbt.net  Sun Dec 13 15:50:30 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 13 Dec 2009 20:50:30 +0000
Subject: [ANN] LMGTWTY: Web Sockets Library for Rack+Rainbows!
In-Reply-To: <20091211115041.GA14610@dcvr.yhbt.net>
References: <20091211115041.GA14610@dcvr.yhbt.net>
Message-ID: <20091213205030.GA30229@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> LMGTWTY is a Rainbows! (and Zbatery) Rack library for Web Sockets.  It

This name was too hard to remember for most folks, so
I'm renaming it to Sunshowers:

  sunshowers at librelist.com

-- 
Eric Wong

From jftucker at gmail.com  Sun Dec 13 16:25:45 2009
From: jftucker at gmail.com (James Tucker)
Date: Sun, 13 Dec 2009 21:25:45 +0000
Subject: [PATCH] env["hack.io"] for Fiber*, Revactor, Thread* models
In-Reply-To: <20091213194553.GC19572@dcvr.yhbt.net>
References: <20091211115041.GA14610@dcvr.yhbt.net>
	<20091211115348.GB14610@dcvr.yhbt.net>
	<20091211115905.GA15621@dcvr.yhbt.net>
	<D3B4FD37-50B9-4913-88E3-92C1B1877ED8@gmail.com>
	<20091213194553.GC19572@dcvr.yhbt.net>
Message-ID: <79B97FEB-3182-491B-8561-1999E3D86246@gmail.com>


On 13 Dec 2009, at 19:45, Eric Wong wrote:

> James Tucker <jftucker at gmail.com> wrote:
>> Testing, all my mails to this ML seem to be getting rejected based on
>> content type, seems Mail.app isn't sending plain, when I tell it to,
>> or it doesn't like my S/MIME
> 
> Hi James,
> 
> Only text/plain is allowed at the moment.

I'd forgotten adding S/MIME to a message means it's not text/plain.

>  And looking at your S/MIME
> signatures on rack-devel, they're humongous compared to the size of the
> message.

Fair call.

> 
> -- 
> 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  Sun Dec 13 18:40:26 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 13 Dec 2009 23:40:26 +0000
Subject: [ANN] Rainbows! 0.9.0
Message-ID: <20091213234025.GA374@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.  For Rack applications not
heavily bound by slow external network dependencies, consider Unicorn
instead as it simpler and easier to debug.

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

Changes:

This release introduces compatibility with Sunshowers, a library
for Web Sockets, see http://rainbows.rubyforge.org/sunshowers
for more information.  Several small cleanups and fixes, too.

-- 
Eric Wong

From normalperson at yhbt.net  Sun Dec 13 18:43:20 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 13 Dec 2009 23:43:20 +0000
Subject: [ANN] Sunshowers - Web Sockets for Ruby, Rack+Rainbows!
Message-ID: <20091213234320.GB374@dcvr.yhbt.net>

Sunshowers is a Ruby library for Web Sockets.  It exposes an easy-to-use
API that may be used in both clients and servers.  On the server side,
it is designed to work with Rack::Request and Rainbows! concurrency
models that expose a synchronous application flow.  On the client side,
it may be used as a standalone wrapper for IO-like objects.

* http://rainbows.rubyforge.org/sunshowers/
* sunshowers at librelist.com
* git://git.bogomips.org/sunshowers.git

It appears works well with the echo_client.py example shipped with
pywebsocket.  It has not been tested against normal web browsers, though
there's no reason it shouldn't work.

== Features

* supports reads and writes of both UTF-8 and binary Web Socket frames

* compatible with Revactor, Rainbows::Fiber::IO and core Ruby IO objects

* pure Ruby implementation, should be highly portable, tested under 1.9

== Install

You may download the tarball from the Rainbows! project page on Rubyforge
and run setup.rb after unpacking it:

http://rubyforge.org/frs/?group_id=8977

You may also install it via RubyGems on Gemcutter:

  gem install sunshowers

== Usage

Make sure you're using one of the following concurrency models
for Rainbows!:

* FiberSpawn
* FiberPool
* Revactor
* ThreadSpawn
* ThreadPool

  # A simple echo server example
  require "sunshowers"
  use Rack::ContentLength
  use Rack::ContentType
  run lambda { |env|
    req = Sunshowers::Request.new(env)
    if req.ws?
      req.ws_handshake!
      ws_io = req.ws_io
      ws_io.each do |record|
        ws_io.write(record)
        break if record == "Goodbye"
      end
      req.ws_quit! # Rainbows! should handle this quietly
    end
    [404, {}, []]
  }

Already using a Rack::Request-derived class?  Sunshowers::WebSocket may
also be included in any Rack::Request-derived class, so you can just
open it up and include it:

  class Sinatra::Request < Rack::Request
    include Sunshowers::WebSocket
  end

See the examples/ directory in the source tree for a client example.

-- 
Eric Wong

From normalperson at yhbt.net  Mon Dec 21 17:10:02 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 21 Dec 2009 14:10:02 -0800
Subject: possible ThreadSpawn + Ruby 1.8 issues
Message-ID: <20091221221002.GA12277@dcvr.yhbt.net>

Anybody else using this combination?  If you are, please let us know
if you have any problems with it or even if it's been working great.

I've heard (privately) about issues with accept() somehow blocking the
entire worker process under 1.8.  Obviously this really should not
happen, but I'm unable to reproduce it myself.

Exact details would be most helpful:

* minor version, patchlevel, distribution of Ruby 1.8

* architecture (green threads may behave differently on 32 vs 64-bit)

* outside patches applied (REE, MBARI, zero-copy context-switch, ...)

* ./configure options (--{disable,enable}-pthread, ...)

* application/gems that use threading features internally
  (includes any uses of the 'timeout' library, which Net::HTTP uses).

* Rainbows! version

Unfortunately, there are also IO.select bugs to worry about, too:

  http://www.daniel-azuma.com/blog/view/z2ysbx0e4c3it9/ruby_1_8_7_io_select_threading_bug
  http://redmine.ruby-lang.org/issues/show/1484

Even though we believe it's bad policy to workaround bugs when they're
fixable, 1.8 users (as evidenced by still using 1.8 :P) can be slow to
upgrade and we'll tolerate workarounds to make ThreadSpawn acceptable
under 1.8 since it's mainly designed with 1.8 in mind.

-- 
Eric Wong

From normalperson at yhbt.net  Mon Dec 21 19:54:21 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 21 Dec 2009 16:54:21 -0800
Subject: [PATCH] possible MRI 1.8 thread fix to avoid blocking accept()
In-Reply-To: <20091221221002.GA12277@dcvr.yhbt.net>
References: <20091221221002.GA12277@dcvr.yhbt.net>
Message-ID: <20091222005421.GA23044@dcvr.yhbt.net>

Under MRI 1.8, listen sockets do not appear to have the
nonblocking I/O flag on by default, nor does it set the
nonblocking I/O flag when calling #accept (but it does
when using #accept_nonblock, of course).

Normally this is not a problem even when using green threads
since MRI will internally select(2) on the file descriptor
before attempting a blocking (and immediately successful)
accept(2).

However, when sharing a listen descriptor across multiple
processes, spurious wakeups are likely to occur, causing
multiple processes may be woken up when a single client
connects.

This causes a problem because accept(2)-ing on multiple
threads/processes for a single connection causes blocking accepts in
multiple processes, leading to stalled green threads.

This is not an issue under 1.9 where a blocking accept() call
unlocks the GVL to let other threads run.
---
  I just pushed this out to git://git.bogomips.org/rainbows.git, too.
  Testers appreciated, thanks.

  Eric Wong <normalperson at yhbt.net> wrote:
  > I've heard (privately) about issues with accept() somehow blocking the
  > entire worker process under 1.8.  Obviously this really should not
  > happen, but I'm unable to reproduce it myself.

 lib/rainbows/base.rb |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/lib/rainbows/base.rb b/lib/rainbows/base.rb
index 211b41c..4a4d076 100644
--- a/lib/rainbows/base.rb
+++ b/lib/rainbows/base.rb
@@ -14,6 +14,12 @@ module Rainbows
       super(worker)
       G.tmp = worker.tmp
 
+      # avoid spurious wakeups and blocking-accept() with 1.8 green threads
+      if RUBY_VERSION.to_f < 1.8
+        require "io/nonblock"
+        LISTENERS.each { |l| l.nonblock = true }
+      end
+
       # we're don't use the self-pipe mechanism in the Rainbows! worker
       # since we don't defer reopening logs
       HttpServer::SELF_PIPE.each { |x| x.close }.clear
-- 
Eric Wong

From normalperson at yhbt.net  Tue Dec 22 15:50:08 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 22 Dec 2009 12:50:08 -0800
Subject: [PATCH 2/1] fix Ruby 1.8 detection for (possible) green thread fix
In-Reply-To: <20091222005421.GA23044@dcvr.yhbt.net>
References: <20091221221002.GA12277@dcvr.yhbt.net>
	<20091222005421.GA23044@dcvr.yhbt.net>
Message-ID: <20091222205008.GA11119@dcvr.yhbt.net>

Thanks to Ben Sandofsky for the extra set of eyes
---

 The patch yesterday was bogus and needs this, also pushed out to
 rainbows.git of course.

 lib/rainbows/base.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/rainbows/base.rb b/lib/rainbows/base.rb
index 4a4d076..20c7681 100644
--- a/lib/rainbows/base.rb
+++ b/lib/rainbows/base.rb
@@ -15,7 +15,7 @@ module Rainbows
       G.tmp = worker.tmp
 
       # avoid spurious wakeups and blocking-accept() with 1.8 green threads
-      if RUBY_VERSION.to_f < 1.8
+      if RUBY_VERSION.to_f < 1.9
         require "io/nonblock"
         LISTENERS.each { |l| l.nonblock = true }
       end
-- 
Eric Wong

From normalperson at yhbt.net  Tue Dec 22 16:34:15 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 22 Dec 2009 13:34:15 -0800
Subject: [PATCH 3/1] base: fix constant resolution under 1.8 for 1.8 bugfix
In-Reply-To: <20091222205008.GA11119@dcvr.yhbt.net>
References: <20091221221002.GA12277@dcvr.yhbt.net>
	<20091222005421.GA23044@dcvr.yhbt.net>
	<20091222205008.GA11119@dcvr.yhbt.net>
Message-ID: <20091222213405.GA14794@dcvr.yhbt.net>

---
 Oops :x

 lib/rainbows/base.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/rainbows/base.rb b/lib/rainbows/base.rb
index 20c7681..a29a5bb 100644
--- a/lib/rainbows/base.rb
+++ b/lib/rainbows/base.rb
@@ -17,7 +17,7 @@ module Rainbows
       # avoid spurious wakeups and blocking-accept() with 1.8 green threads
       if RUBY_VERSION.to_f < 1.9
         require "io/nonblock"
-        LISTENERS.each { |l| l.nonblock = true }
+        HttpServer::LISTENERS.each { |l| l.nonblock = true }
       end
 
       # we're don't use the self-pipe mechanism in the Rainbows! worker
-- 
Eric Wong

From normalperson at yhbt.net  Tue Dec 22 17:14:28 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 22 Dec 2009 22:14:28 +0000
Subject: [ANN] Rainbows! 0.90.0 - Thread* fixes and RevFiberSpawn
Message-ID: <20091222221428.GA29086@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.  For Rack applications not
heavily bound by slow external network dependencies, consider Unicorn
instead as it simpler and easier to debug.

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

Changes:

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.
-- 
Eric Wong

From normalperson at yhbt.net  Tue Dec 22 18:10:25 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 22 Dec 2009 23:10:25 +0000
Subject: [ANN] Zbatery - for newer Rainbows!
In-Reply-To: <20091222221428.GA29086@dcvr.yhbt.net>
Message-ID: <20091222231025.GA30136@dcvr.yhbt.net>

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.

Zbatery will still exploit certain features of Unix for transparent
upgrades, log reopening, and graceful stops, but does not rely on them
for basic functionality.

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

Changes:

This gem release allows compatibility with newer versions of
Rainbows!  This also fixes a bug when $stdout is not redirected
to a file.

-- 
Eric Wong

From admin at ebuppies.com  Mon Dec 21 17:54:28 2009
From: admin at ebuppies.com (ebuppies admin)
Date: Mon, 21 Dec 2009 17:54:28 -0500
Subject: eBuppies.com - Offers New Online Dating Site for Black Urban
	Professionals
Message-ID: <e70a2bae87dfe7c87e9fd253acf46766@mail.ebuppies.com>



 <http://www.ebuppies.com/tellafriend.php>

 December 18, 2009

 <http://www.ebuppies.com/signup.php>

 Dear Friend, <http://www.ebuppies.com>

 eBuppies.com (www.ebuppies.com <http://www.ebuppies.com/signup.php>
) is a new online dating site that is dedicated to providing singles
from all over with the opportunity to connect with other buppy singles
in their local area or anywhere of their choice. 

 More and more buppy singles are going online to connect with others
because going out week after week to nightclubs and bars can be
tiresome, as well as expensive. eBuppies.com makes dating easy by
hosting hundreds of profiles of different singles looking for love.
Buppies can join on a monthly basis for less than they would probably
pay for one night at a nightclub or bar.

 Buppies who are looking for love, romance or just friendship now have
a unique resource that can help them discover their future soul mate:
eBuppies.com. 

 Although high technology drives eBuppies.com, the online dating site
is simple and easy for buppies to navigate. Buppies can register,
browse, search and contact other singles
<http://www.ebuppies.com/signup.php>
at no charge. There is also no charge for buppies to upload a photo
with their profile. A control panel enables buppies to customize
preferences based on their individual requirements. The control panel
also blocks undesired contacts for buppies' convenience.

 The pricing for membership is quite cost effective especially for the
average buppy. By January 31 2010 visitors can sign up for 1 Month and
get 30 Days extra membership exclusively through our THIRTYPLUS
<http://www.ebuppies.com/signup.php>
 promo code.

 For more information, visit www.ebuppies.com.
<http://www.ebuppies.com/signup.php>

 About eBuppies.com:

 eBuppies.com is a new online dating service based in San Francisco.
Its goal is to provide easy and affordable online dating to Black
Urban Professionals by using state of the art chat systems, instant
messaging, and forum technology to satisfy today's evolving online
community demands.

 Terms of use <http://www.ebuppies.com/index.php?page=terms_of_use>

 Contact Info:

 Name: Mr. F. Jackson

 Address: 1230 Market Street, #252

 City: San Francisco

 State: California

 Country: United States

 Zip: 94102

 Web Address: www.ebuppies.com <http://www.ebuppies.com/signup.php>

 Phone: 510-575-4124

 /

 /

 / / <http://www.ebuppies.com/signup.php>

 Site Statistics

 Special Offer!

 			Members in Last Week: 		
 			1 		

 Total Male eBuppies:
 			10 		

 			Total Female eBuppies: 		
 15 		

 Pictures in Last Week: 		
 0 		

 Members online: 		
 0

 News

 Women More Likely to Snoop Than Men

 Nov 24, 2009

 In the new film, Little Black Book, Brittany Murphy's character
engages in some high-tech snooping on her new boyfriend. Based...

 				more <http://www.ebuppies.com/signup.php>

 Internet Dating More Successful than Thought

 Nov 24, 2009

 Internet dating is proving a much more successful way to find
long-term romance and friendship for thousands of people than...

 				more <http://www.ebuppies.com/signup.php>

 			All News <http://www.ebuppies.com/signup.php>

 Poll

 <http://www.ebuppies.com/signup.php>

 Success Stories

 A Sister's Story

 Sep 11, 2009

 by				 			Monique <javascript:popUpScrollWindow2(>

 What initially started out as something to relieve a little boredom
and to have some fun turned into one of...

 more <http://www.ebuppies.com/signup.php>

 All Stories <http://www.ebuppies.com/signup.php>

 <http://www.ebuppies.com/signup.php>

 Welcome to eBuppies.com

 See why eBuppies.com is the fastest growing Black Urban Professional
relationship site on the web. Create your eBuppies.com profile to
begin the exciting journey towards finding your match.

 Members online: 0 <http://www.ebuppies.com/onlineusers.php>

 Don't stay alone, Join Now for Free
<http://www.ebuppies.com/signup.php>

 Newest eBuppies

 							 						kldixson 			 			 <http://www.ebuppies.com/signup.php>

 							 						systemsthinking 			
<http://www.ebuppies.com/signup.php>

 Show full list <http://www.ebuppies.com/signup.php>

 Newest Profiles

 brotherX <http://www.ebuppies.com/signup.php>

 *Age:*
 40

 *Gender:*
 Man

 *Looking for:*
 Woman

 *Location:*
 Albany, 

 California, 

 United States

 <javascript:popUpScrollWindow2(>

 No Pictures

 *Active wihin 1 week*
 View Profile <http://www.ebuppies.com/signup.php>

 kldixon <http://www.ebuppies.com/signup.php>

 *Age:*
 40

 *Gender:*
 Man

 *Looking for:*
 Woman

 *Location:*
 Oakland, 

 California, 

 United States

 <javascript:popUpScrollWindow2(>

 No Pictures

 *Active wihin 1 week*
 View Profile <http://www.ebuppies.com/signup.php>

 Login <http://www.ebuppies.com/signup.php>
 | 				 Privacy <http://www.ebuppies.com/signup.php>
 | 		 Terms of Use <http://www.ebuppies.com/signup.php>
 | 		 Services <http://www.ebuppies.com/signup.php>
 | 		 FAQ's <http://www.ebuppies.com/signup.php>
 | 		 Articles <http://www.ebuppies.com/signup.php>
 | 		 Affiliate <http://www.ebuppies.com/signup.php>
 | 	 Invite a Friend <http://www.ebuppies.com/signup.php>
 | 		 Feedback <http://www.ebuppies.com/signup.php>



<table cellspacing="0" cellpadding="2" border="0" width="100%">
    <tbody>
        <tr>
            <td colspan=3 align=right ><font face="arial,verdana"
size="2">If you do not want to receive any more newsletters, 
http://ebuppies.com/emailserv/?p=unsubscribe&uid=27fcf3cec90d320e7586a5af9ad57bfc
To update your preferences and to unsubscribe visit
http://ebuppies.com/emailserv/?p=preferences&uid=27fcf3cec90d320e7586a5af9ad57bfc
Forward a Message to Someone
http://ebuppies.com/emailserv/?p=forward&uid=27fcf3cec90d320e7586a5af9ad57bfc&mid=20</font></td>
</tr>
        <tr>
            <td><font face="arial,verdana" size="1">CUBEMEDIALAB<br><br />
            1230 Market Street<br>
            Suite 252<br>
            San Francisco, California 94102<br>
            USA<br />
             </font></td><br />
            <td align="right"><a href="http://www.cubemedialab.com"
target="_blank"><img border="0"
src="http://www.ebuppies.com/images/cube_logo.gif" alt="Try digital design
with cubemedialab.com!" /></a></td><br />
        </tr>
    </tbody>
</table>



--
Powered by PHPlist, www.phplist.com --




From normalperson at yhbt.net  Sat Dec 26 18:27:32 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 26 Dec 2009 15:27:32 -0800
Subject: deferrable bodies in Rainbows!
In-Reply-To: <AA4E98A6-3E73-49B5-8B43-B1E7718365A9@gmail.com>
References: <9363563c-cbd4-498f-b9ee-b3ee83fa15b8@r5g2000yqb.googlegroups.com>
	<20091224224956.GB4847@dcvr.yhbt.net>
	<1c5622660912241540v74329427nd1053b6e602e6506@mail.gmail.com>
	<20091225002451.GA1821@dcvr.yhbt.net>
	<AA4E98A6-3E73-49B5-8B43-B1E7718365A9@gmail.com>
Message-ID: <20091226232732.GA26351@dcvr.yhbt.net>

Moving to rainbows list

James Tucker <jftucker at gmail.com> wrote:
> Eric - I had a report from one of the async_sinatra users who tried
> out rainbows with EM, and found that the API didn't actually line up
> with what Thin was doing. I really want to devote some more time with
> this but I've been very busy. Sadly due to this I don't want to say
> stop, but, well, I want to say please check existing apps against it.
> I guess could you check async_*.ru from
> github.com/macournoyer/thin/master/tree/examples/async_*.ru, as from
> what was reported, they're not working with the rainbows
> implementation of the deferrablebody hacks.

Hi James, thhanks for the heads up.

Rainbows! doesn't handle deferrable bodies yet (I didn't look closely enough
the first time around), so it can't do everything Thin does with EM, yet.
It's already in the TODO, I'll make a mental note to work on it sooner.

-- 
Eric Wong

From jftucker at gmail.com  Sat Dec 26 20:21:35 2009
From: jftucker at gmail.com (James Tucker)
Date: Sun, 27 Dec 2009 01:21:35 +0000
Subject: deferrable bodies in Rainbows!
In-Reply-To: <20091226232732.GA26351@dcvr.yhbt.net>
References: <9363563c-cbd4-498f-b9ee-b3ee83fa15b8@r5g2000yqb.googlegroups.com>
	<20091224224956.GB4847@dcvr.yhbt.net>
	<1c5622660912241540v74329427nd1053b6e602e6506@mail.gmail.com>
	<20091225002451.GA1821@dcvr.yhbt.net>
	<AA4E98A6-3E73-49B5-8B43-B1E7718365A9@gmail.com>
	<20091226232732.GA26351@dcvr.yhbt.net>
Message-ID: <9D8F97A8-F08E-437E-82EE-AD885824291A@gmail.com>


On 26 Dec 2009, at 23:27, Eric Wong wrote:

> Moving to rainbows list
> 
> James Tucker <jftucker at gmail.com> wrote:
>> Eric - I had a report from one of the async_sinatra users who tried
>> out rainbows with EM, and found that the API didn't actually line up
>> with what Thin was doing. I really want to devote some more time with
>> this but I've been very busy. Sadly due to this I don't want to say
>> stop, but, well, I want to say please check existing apps against it.
>> I guess could you check async_*.ru from
>> github.com/macournoyer/thin/master/tree/examples/async_*.ru, as from
>> what was reported, they're not working with the rainbows
>> implementation of the deferrablebody hacks.
> 
> Hi James, thhanks for the heads up.
> 
> Rainbows! doesn't handle deferrable bodies yet (I didn't look closely enough
> the first time around), so it can't do everything Thin does with EM, yet.
> It's already in the TODO, I'll make a mental note to work on it sooner.

Making this stuff work correctly in sync and async is one of the things that kills a rack.io style api, particularly for an abstracted IO layer like eventmachine (where you can't extract and hand out the raw IO without causing signficant complication + problems (we're never gunna support read(3) and EM buffered reads in concurrently under EM for obvious reasons)). This means such APIs can be problematic to implement properly, forcing people to buffer and pack in StringIO and whatnot. There are some more hacks one can do ofc, but I'd rather come up with an API that's good for all, whilst still being performant (this is possible, I am certain).

Sorry for yet another rushed reply (starting to feel real bad about that over here) :(

P.S. This S/MIME rejection is really starting to grate me, I'm wishing Mail.app had the ability to forcibly stop doing that for specific addresses, but their S/MIME support is as embedded as most other clients (for mostly better, and occasionally worse).

From normalperson at yhbt.net  Sat Dec 26 21:16:03 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 26 Dec 2009 18:16:03 -0800
Subject: deferrable bodies in Rainbows!
In-Reply-To: <9D8F97A8-F08E-437E-82EE-AD885824291A@gmail.com>
References: <9363563c-cbd4-498f-b9ee-b3ee83fa15b8@r5g2000yqb.googlegroups.com>
	<20091224224956.GB4847@dcvr.yhbt.net>
	<1c5622660912241540v74329427nd1053b6e602e6506@mail.gmail.com>
	<20091225002451.GA1821@dcvr.yhbt.net>
	<AA4E98A6-3E73-49B5-8B43-B1E7718365A9@gmail.com>
	<20091226232732.GA26351@dcvr.yhbt.net>
	<9D8F97A8-F08E-437E-82EE-AD885824291A@gmail.com>
Message-ID: <20091227021603.GB28140@dcvr.yhbt.net>

James Tucker <jftucker at gmail.com> wrote:
(snip stuff I mostly agree with, pondering some still...)
> Sorry for yet another rushed reply (starting to feel real bad about
> that over here) :(

No worries, at least the message got through.

> P.S. This S/MIME rejection is really starting to grate me, I'm wishing
> Mail.app had the ability to forcibly stop doing that for specific
> addresses, but their S/MIME support is as embedded as most other
> clients (for mostly better, and occasionally worse).

I'll consider allowing signatures if it makes your life easier...

However I strongly believe the content of messages trumps the identity
of the sender, and signatures in public correspondence shouldn't matter.

-- 
Eric Wong

From jftucker at gmail.com  Sat Dec 26 21:32:53 2009
From: jftucker at gmail.com (James Tucker)
Date: Sun, 27 Dec 2009 02:32:53 +0000
Subject: deferrable bodies in Rainbows!
In-Reply-To: <20091227021603.GB28140@dcvr.yhbt.net>
References: <9363563c-cbd4-498f-b9ee-b3ee83fa15b8@r5g2000yqb.googlegroups.com>
	<20091224224956.GB4847@dcvr.yhbt.net>
	<1c5622660912241540v74329427nd1053b6e602e6506@mail.gmail.com>
	<20091225002451.GA1821@dcvr.yhbt.net>
	<AA4E98A6-3E73-49B5-8B43-B1E7718365A9@gmail.com>
	<20091226232732.GA26351@dcvr.yhbt.net>
	<9D8F97A8-F08E-437E-82EE-AD885824291A@gmail.com>
	<20091227021603.GB28140@dcvr.yhbt.net>
Message-ID: <F0380D37-AB9B-4CD6-A77B-0F754C8ABD1D@gmail.com>


On 27 Dec 2009, at 02:16, Eric Wong wrote:

> James Tucker <jftucker at gmail.com> wrote:
> (snip stuff I mostly agree with, pondering some still...)
>> Sorry for yet another rushed reply (starting to feel real bad about
>> that over here) :(
> 
> No worries, at least the message got through.
> 
>> P.S. This S/MIME rejection is really starting to grate me, I'm wishing
>> Mail.app had the ability to forcibly stop doing that for specific
>> addresses, but their S/MIME support is as embedded as most other
>> clients (for mostly better, and occasionally worse).
> 
> I'll consider allowing signatures if it makes your life easier...

No don't worry, I just need to get used to it :-S

> 
> However I strongly believe the content of messages trumps the identity
> of the sender, and signatures in public correspondence shouldn't matter.

I'd agree if I hadn't had a distasteful person spoof me in the past in an attempt to defame my character. The person in question was reprimanded, but, in that case it was easy to track him down - not that I expect that to happen in this community.

Don't worry about changing anything, I'll stop whining (sorry) :)

> -- 
> 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  Wed Dec 30 05:34:38 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 30 Dec 2009 02:34:38 -0800
Subject: [ANN] Rainbows! 0.90.1 - EM::Deferrables and quieter Threads
Message-ID: <20091230103438.GA6852@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.  For Rack applications not
heavily bound by slow external network dependencies, consider Unicorn
instead as it simpler and easier to debug.

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

Changes:

This release contains minor bugfixes/compatibility improvements
for ThreadSpawn, ThreadPool and EventMachine users.

Excessive error messages from spurious wakeups using
ThreadSpawn/ThreadPool under most platforms are silenced.  Only
Ruby 1.9 users under Linux were unaffected by this bug.

EventMachine users may now use EM::Deferrable objects in
responses, vastly improving compatibility with existing
async_sinatra apps.

-- 
Eric Wong

From normalperson at yhbt.net  Wed Dec 30 05:47:29 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 30 Dec 2009 10:47:29 +0000
Subject: deferrable bodies in Rainbows!
In-Reply-To: <20091226232732.GA26351@dcvr.yhbt.net>
References: <9363563c-cbd4-498f-b9ee-b3ee83fa15b8@r5g2000yqb.googlegroups.com>
	<20091224224956.GB4847@dcvr.yhbt.net>
	<1c5622660912241540v74329427nd1053b6e602e6506@mail.gmail.com>
	<20091225002451.GA1821@dcvr.yhbt.net>
	<AA4E98A6-3E73-49B5-8B43-B1E7718365A9@gmail.com>
	<20091226232732.GA26351@dcvr.yhbt.net>
Message-ID: <20091230104729.GA26287@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> Moving to rainbows list
> 
> James Tucker <jftucker at gmail.com> wrote:
> > Eric - I had a report from one of the async_sinatra users who tried
> > out rainbows with EM, and found that the API didn't actually line up
> > with what Thin was doing. I really want to devote some more time with
> > this but I've been very busy. Sadly due to this I don't want to say
> > stop, but, well, I want to say please check existing apps against it.
> > I guess could you check async_*.ru from
> > github.com/macournoyer/thin/master/tree/examples/async_*.ru, as from
> > what was reported, they're not working with the rainbows
> > implementation of the deferrablebody hacks.
> 
> Hi James, thhanks for the heads up.
> 
> Rainbows! doesn't handle deferrable bodies yet (I didn't look closely enough
> the first time around), so it can't do everything Thin does with EM, yet.
> It's already in the TODO, I'll make a mental note to work on it sooner.

Rainbows! 0.90.1 should support deferrable bodies needed for async apps
on EM.

I stole the async_app.ru and async_tailer.ru examples from Thin and made
them a part of the integration tests (in t/t04??-*.sh).


The app.deferred?(env) isn't supported, yet.  It's in the TODO and I
don't think many people use it... (correct me if I'm wrong).

-- 
Eric Wong