As detailed in issue #48, curb does not directly allow setting certain timeout options available in curl. This would have been a minor inconvenience if curb exposed curl_easy_setopt call (and corresponding multi-call, if any). Even without any CURLOPT_* constants defined I could still pass appropriate magic numbers to curl_easy_setopt and have a workaround for timeout functionality until a better solution is put in place. Currently I have no choice but to edit C extension code, followed by distributing and installing custom packages to/on a number of development and production systems.
Curb should expose curl_easy_setopt, perhaps with a warning that it is possible to break things by passing certain values to it (e.g. options that take C strings as arguments for example), for cases when it does not provide a "native" interface to some functionality.
or you send me a patch and if looks solid has some test coverage i'd add it to the next release...
I thought you might say that :)
I filed the ticket first in case the functionality already existed and I just couldn't find it.
I had a need for this as well ("delete=" and "head=" are implemented, but not "delete" and "head" to return a boolean).
yep, libcurl bindings for ruby are in need of a rewrite... i just don't have the time.
I started working on this and testing of setopt passthrough is rather tricky.
By design curb issues setopt calls when curb#perform is called, and forwarded setopts happen before that. This makes it impossible to use setopt passthrough to set an option that is explicitly supported by curb.
This, in turn, means that to test that setopt passthrough works we need to use options that are not supported by curb. This is not only a relatively small and obscure set, but one that is shrinking with time as curb gains features. It may be the case that for less frequently used value types there simply are not any options that curb does not natively handle, and so such types would be untestable.
This could be avoided by storing the options and values given to curb's setopt in a list and issuing them to libcurl after curb sets its own options. This should work reasonably well but obviously requires memory (including dynamic allocation) to store the options.
yeah my real thought here is i agree and I think the design of the original gem needs a rewrite... IMO it would better serve us to have libcurl bindings that implemented a thin passthrough over the libcurl easy/multi/shared interfaces.
Ideally, this would include the socket interfaces allowing us to use eventmachine or cool.io (maybe) as event loops... it also means a lot less C and a lot more ruby.
I have a local branch I need to push - I've had it for too long just sitting. have wanted to get this written for almost 2 years now...
Keeping this ticket open. There is a set interface now, but it's still very minimal as far as what can be set.