Typhoeus Another libcurl Ruby binding?
I just saw this today: http://www.pauldix.net/2009/05/breath-fire-over-http-in-ruby-with-typhoeus.html Looks like a really nice library. I really like the libcurl easy bindings it provides.
I just saw this today: http://www.pauldix.net/2009/05/breath-fire-over-http-in-ruby-with-typhoeus.html Looks like a really nice library. I really like the libcurl easy bindings it provides.
I added a new callback hook to curb on_success and on_failure. They work as advertised and are esspecially useful when using the Curl::Multi interface from my last patch.
gc = Curl::Easy.new("http://www.google.com/")
gc.on_success{|curl| puts curl.body_str }
yc = Curl::Easy.new("http://www.yahoo.com/")
yc.on_success{|curl| puts curl.body_str }
mc = Curl::Multi.new
mc.add(gc)
mc.add(yc)
mc.perform
I’ve updated my patch for curb multi interface and tested against valgrind for memory leaks. So far the patch looks stable. I’m still waiting to hear from the curb author. In the meantime here’s how to apply the patch if you’re interested.
svn co svn://rubyforge.org/var/svn/curb/TRUNK/curb
wget http://taf2-patches.s3.amazonaws.com/curb-multi.patch
patch -p0 < curb-multi-3.patch
I spent the day working on adding multi interface support to curb. I really like the curb ruby interface and with a little work can now use the same Curb::Easy interface and run the handles through the asynchronous Curb::Multi interface. The patch hasn’t been rigorously tested, but hey not bad for my first day.
Here’s the patch
I started to put together some benchmarks to validate my work on evdispatch. Here’s what I have so far…
Curb as a pure C extension runs on the main ruby thread, meaning no ruby threads can be schedule while it’s blocking. It uses the easy curl interface meaning it’s all blocking. This makes it very easy to use and for single requests it’s great. For multiple requests, it’s as though all the requests are made one after the other in serial.
Read more…
Here it is version 0.2.6.
This version fixes a bug when sending an HTTP POST on apple/darwin Mac OS.
curl_easy_setopt( m_handle, CURLOPT_POST, 1 );
// set the buffer size to copy
curl_easy_setopt( m_handle, CURLOPT_POSTFIELDSIZE, value.length() );
curl_easy_setopt( m_handle, CURLOPT_POSTFIELDS, value.c_str() );
// copy the buffer
curl_easy_setopt( m_handle, CURLOPT_COPYPOSTFIELDS, value.c_str() );
I had to set the CURLOPT_POSTFIELDS before calling CURLOPT_COPYPOSTFIELDS.
In my next release I hope to have support for setting arbitrary HTTP headers. I’ll also be working on a streaming response interface. In my C++ library I already have a working example that lets the response from the event loop be written directly to a file descriptor. To expose this in Ruby I would make it so any IO object can be passed into the request method via a :stream => io parameter. This only posses one interesting issue that the Ruby StringIO could be valid to pass, but my implementation would not be able to pull a file descriptor from the StringIO object. Perhaps, when it’s an IO object without a file descriptor my implementation could create a pipe fd on behave of the caller?
Recent Comments