Manual async requests by default

[Julien Portalier]

Hi,

I was wondering why async requests were to be manually called, either
with aget or get :sync => true, and not called automatically depending
on the availability of EM::HttpRequest? Is there a particular reason
for it?

Something like this:

def request(opts, *req, &cb)
if defined?(EM::HttpRequest)
em_request(opts, *req, &cb)
else
rc_request(opts, *req, &cb)
end
end

Or maybe we could have a default async option?

[Lin Jen-Shin (aka godfat 真常)]

Hi,

On Tue, Feb 8, 2011 at 10:48 PM, Julien Portalier <ysbad...@gmail.com> wrote:
> Hi,
>
> I was wondering why async requests were to be manually called, either
> with aget or get :sync => true, and not called automatically depending
> on the availability of EM::HttpRequest? Is there a particular reason
> for it?
>
> Something like this:
>
> def request(opts, *req, &cb)
> if defined?(EM::HttpRequest)
> em_request(opts, *req, &cb)
> else
> rc_request(opts, *req, &cb)
> end
> end
>

Because async requests and sync requests are very different, doing:

require 'em-http'

should not change the semantic of requests so much.
In async requests, you need to pass callback anyway,
(please put em-synchrony aside for now), but in sync
requests, you can simply get the response from the
return of the method call.

data = rest_graph.get('me')

vs

rest_graph.aget('me'){ |data|
# now we have data
}

It's totally different work flow, unless you use callback
form for sync requests as well:

rest_graph.get('me'){ |data|
# now we have data
}

Switching from sync to async is not trivial at all.
I haven't tried using em-synchrony with rest-graph
though. It might introduce other complexities.
(e.g. can't yield from root fiber)

> Or maybe we could have a default async option?

This is ok, but I wonder if you really need it?
Could you show me your use cases?

cheers,

[Julien]

Ok, I get it now. Those are real async calls and not async call that looks like they're synced. I was spoiled by em-synchrony and ruby 1.9 fibers.

My use case is a classic rails website, running ruby 1.9 and a thin server to process requests with event machine. I'd like the facebook api requests to not block the whole process, so that it can process other requests while waiting for the answer. But I don't really know how it actually works.

J.

[Lin Jen-Shin (aka godfat 真常)]

Hi,

Interesting, does it work well? We have a Ramaze application running
with em-synchrony on Thin, and it's not so easy to do it right. I need to
put Fiber.new{ ... }.resume occasionally, and exceptions are hard to
deal with as well. We don't use rest-graph on that application though.
Would this work on your application?

data = rest_graph.aget('me')

If that's the case, then I might be happy to enable async mode
automatically as you demonstrated when em-synchrony and
em-http is both available.

cheers,
Jen-Shin