From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: * X-Spam-ASN: AS14383 205.234.109.0/24 X-Spam-Status: No, score=1.0 required=3.0 tests=HK_RANDOM_FROM, MSGID_FROM_MTA_HEADER shortcircuit=no autolearn=no version=3.3.2 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: rainbows for 3rd party api Date: Thu, 5 Nov 2009 15:06:39 -0800 Message-ID: <20091105230638.GA7131@dcvr.yhbt.net> References: <2007122a0911041049u2b4376dbpd3b1f727e315ea88@mail.gmail.com> <20091104214018.GA25942@dcvr.yhbt.net> <2007122a0911050503x5740cf3ei4f1185b4cb895298@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1257462913 17848 80.91.229.12 (5 Nov 2009 23:15:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2009 23:15:13 +0000 (UTC) To: Rainbows! list Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Fri Nov 06 00:15:00 2009 Return-path: Envelope-to: gclrrg-rainbows-talk@m.gmane.org X-Original-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Delivered-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Content-Disposition: inline In-Reply-To: <2007122a0911050503x5740cf3ei4f1185b4cb895298-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Xref: news.gmane.org gmane.comp.lang.ruby.rainbows.general:20 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.50) id 1N6BXg-0003v0-B5 for gclrrg-rainbows-talk@m.gmane.org; Fri, 06 Nov 2009 00:15:00 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 8C35818582AC; Thu, 5 Nov 2009 18:14:59 -0500 (EST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id E932918582AC for ; Thu, 5 Nov 2009 18:06:40 -0500 (EST) Received: from localhost (unknown [127.0.2.5]) by dcvr.yhbt.net (Postfix) with ESMTP id C066F1F4EA; Thu, 5 Nov 2009 23:06:39 +0000 (UTC) Giovanni Lion wrote: > > Hi Giovanni, > > > > 3rd party API responses are exactly one of the uses Rainbows! was built > > for. > > > > You really only want DevFdResponse if you're doing a straight proxy > > between the 3rd party and your client without modifying the data. =A0Si= nce > > you seem to be getting XML and rendering HTML, you probably can't use > > DevFdResponse efficiently. =A0Don't despair, though, Rainbows! still > > gives you plenty of options :) > > > > You can build a Rack config.ru to use with Rails, too. In fact, you'll > > have to for now since we're unsure if we want to support a > > "rainbows_rails" wrapper like I do with "unicorn_rails". =A0Using > > config.ru gives you much more flexibility to route around/outside > > of Rails. > = > Ok i think i got most of it. Now i was just thinking about the best > way to get this going. The issue now is that processing the xml into > the html is something I prefer keeping insde the app for consistency. > My idea was to do something like this, i use an example this time: > = > 1) I get a request for a friend list html partial > 2) I intercept it and using revactor > 3) Wait for the response (It shouldn't be called waiting with revactor > and fibers, right?) Well, from the caller's point of view, it is waiting :) > 4) I write the response to memcached > 5) I call the rails app who now fetches from cache the friend list > 6) The rails app renders the partial and everybody is happy > = > Do you think this is a good flow? Should I create a specific method inste= ad? Depends on the rest of your app, I guess. Is your Rails app reentrant? If so, definitely go for it. If you're dealing with DB connections in there, compatibility will probably be better with the ThreadPool or ThreadSpawn models unless somebody writes Revactor-enabled DB libraries. > Also, another issue is not clear to me yet. I need to make api > requests with oauth, hence there is a logic layer on top of the http > request. I would probably need to brake it down and replace Net:HTTP > with Revactor::HttpClient, am i correct? Yes. To effectively use Revactor you pretty much have to change any parts of your app/libraries to use Revactor's networking API. Fortunately it's not too hard since program logic is still linear with the Actor model. You might even want to do it for memcached, too, but then again memcached is pretty fast on a LAN and you might not notice it block. -- = Eric Wong