unwire / handsoap

thanks for the heads up. We are currently looking into the issue

Gem is now at: http://gemcutter.org/gems/handsoap

Btw, to enable cookie support for the curb driver, add the following to your initializer after applying the patch:

Handsoap.http_driver = :curb
Handsoap::Http.drivers[:curb].http_client.enable_cookies = true

The relevant feature-adding commit is this: http://github.com/rud/handsoap/commit/acaa5f5ec94147a752cde5d001ccebb9b6c516c3

Since the refactoring to enable async http, this patch can't be applied directly. I've integrated it manually instead. Notice that I made some changes; I do not like to let the driver maintain state by default, as this could lead to some very hard-to-track-down bugs. To use it, you'll have to override the method http_driver_instance in your service class. Eg.:

class MyService < Handsoap::Service
  def http_driver_instance
    unless @driver_instance
      @driver_instance = Handsoap::Http.drivers[Handsoap.http_driver].new
      @driver_instance.enable_cookies = true
    end
    @driver_instance
  end
end

Currently, only the curb driver implements support for enable_cookies, although I assume the other drivers have similar capabilities (or it could be implemented in the abstraction layer)

I suspected you had a reason for creating new instances for each request, even though it clashed with my use-case.

Your suggested service-change is clean and explicit - I'll be integrating it in my service shortly.

Thank you for the quick feedback and integration! :)

Just found the "track build progress" page: http://hasmygembuiltyet.org/unwire/handsoap

It seems that github no longer supports building gem.
This was pointed out here: http://github.com/unwire/handsoap/issues#issue/5 (this issue also has a deep link to the actual github blog post)

We'll try to keep both issues up-to-date, and will try to get the new gem up asap

Gem is now at: http://gemcutter.org/gems/handsoap

Works - just successfully installed handsoap-1.1.0 gem from gemcutter :)

Fixed in http://github.com/unwire/handsoap/commit/56c5a101872b886b38a954e4c8d3f1cf34dc9874

By heavyweight, I assume that you mean raw performance? If that is the case, did you actually measure the difference between dom traversal and xpath querying? My gut feeling is that the difference is much smaller than you might think. In the case of xmllib/nokogiri, the xpath querying happens in the external library, which is presumably quite efficient. Traversing the dom would potentially be more intensive than querying. Now, I don't have any metrics, so this is just my best guess, but I would suggest that you measure it. Even if traversal is faster, you would probably need very large datasets for it to matter; The time taken to parse the xml and in the http-layer will most likely dwarf it by comparison.

That said, an xpath query offers a level of abstraction, which is probably better for your application design. With traversal, you have a tendency to make assumptions about the structure of the xml, so if it changes your application may break easier.

I agree that hard numbers are useful for this sort of thing, so following is my benchmark:

            user     system      total        real
DOM     4.920000   0.200000   5.120000 (  6.703107)
xpath  16.030000   0.290000  16.320000 ( 18.201955)

This was for a dataset of two weeks of one-minute data, thus 20160 data points. For the DOM solution, I used native_element to get at the underlying Nokogiri nodes. My use case may be atypical, of course, and I'm not worried about cross-XML-library compatibility for this particular code, so I can understand if you'd prefer to leave this sort of thing out of the API.

I must say, that was a bigger difference than I expected. Probably because you are calling xpath twice, thereby hitting the external api twice, rather than just one call to #children. I've added a #children method to the api now, so you can use it without sacrificing portability.