Use futuroscope to run API calls in the background

[josepjaume]

I had to change some tests and add an inspect because otherwise the test would have died without letting the thread make its work.

By calling inspect (or any other method, really) we force it to wait for a result.

I believe the speed improvements will be enormous.

[oriolgual]

It would be nice to have some kind of benchmark :P

[oriolgual]

Also, I was thinking to enforce the use of NetHTTPPersistent (since it's supported by Faraday) to help reducing the number of connections.

[josepjaume]

That would be great!

Let's see if I can run some benchmarks tomorrow :)

[bkeepers]

Could you explain where the speed improvements will come from? I'm not sure I see it. It seems like for most uses, the future will have to resolve for each object before the next one is created. For example, if I wanted to get the titles from an array of links:

Hyperclient.new(url).links[:categories].each {|c| puts c.attributes.name }

c.attributes will create the future, but .name has to wait for it to resolve, which happens before all the requests are created.

Am I missing something?

[txus]

I rebased with current master. @josepjaume maybe you could provide some example code to show where the benefits could be?

[txus]

Merging, but not releasing a new version yet. We'll see if we run into any problems.

[langalex]

I would propose to remove this again:

1. As stated above there's probably zero performance gain in most cases as the calls all are sequential/depend on each other
2. It's not apparent when using hyperclient that it uses futures internally, which can lead to problems, i.e. making a POST/PUT request without checking the response -> returns a future -> network problem causes exception but this is ignored as the program has already moved on
3. Potential problems with non thread-safe code (?)

I think it would be more appropriate to use futures directly in an app where you are aware of the implications.