Hey Aaron,
So the obvious question is why didn't you build off the libxml-ruby bindings? And then the next obvious question, would it be better to combine efforts? Seems to me that would be much preferable.I tried to build off the libxml-ruby bindings. You'll notice the 7 patches I submitted back in July: http://skitch.com/aaronpatterson/hdyw/rubyforge-libxml-mozilla-firefox-build-2008102920 (looks like I've submitted more patches than anyone else) The velocity of libxml-ruby development was too slow for me. I have severe ADD (not really, but I am impatient), and waiting for my patches to get applied or rejected was too much work and took too muchtime.
Ah, fair enough. Its a good point and I'm trying to act more quickly on patches (fyi, I think all of yours are applied now). Sorry that we didn't respond quickly enough - we definitely don't want to drive people away.
After trying to build the functionality I needed on top of libxml-ruby, I finally got tired of contorting around the API. These hindering aspects made writing my own library seem like the path of least resistance.
Yup, makes sense. I'm wondering though, since Ruby is so flexible, if it would be possible to put different apis on top of the underlying C code. And the C core is the hard bit, maybe we can share that?
I know you were in favor of moving as much of the api as possible to Ruby, and I agree with that, and have been doing that.
And as far as installation and namespace discussions, I think we're finally past those (thankfully).
I just integrated a patch for adding Hpricot like api to libxml, and would be really interested in adding in CSS3 selector support (I took a quick look through the Nokogiri code for this, and would be happy to port it over to libxml lock-stock-and-barrel if that's ok with you).Great! Nokogiri has an MIT license, so go for it. :-)
Cool - its a neat feature.
So we're happy to work together on our end.We are too. Feel free to steal our code, or submit patches: http://github.com/tenderlove/nokogiri/tree/master We'd be happy to have you help. :-) Right now there are a few major things I want to add: * JRuby/Rubinius support via FFI * DOM1 implementation (other versions later) * Custom XPath functions
So, a few more thoughts. In the end, how much different is nokogiri's api versus libxml? Is it really different, or just some changes around the edges (like find is called search, etc.).
Thinking about future development, it seems we could: * Have two separate projects, where we borrow code, share ideas, etc.* Move to a single C code base, but still have two different projects where each provides its own api. * Have one project, where we let the user provide different apis (Hpricot, Nokogiri, libxml-ruby, Rexml).
Note sure if #2 or #3 are viable, but I'd be happy to give it some more thought. I'm also happy to add you guys in as developers to libxml-ruby (so you don't have to wait around for me to do stuff).
Let me know what you think! Charlie Savage http://cfis.savagexi.com
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
