On Wed, Nov 19, 2008 at 01:09:06PM -0700, Charlie Savage wrote: >> 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'm not sure. I haven't looked at the libxml-ruby source in a few months now, but I believe our memory management schemes are different. > > 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.). I'm not sure. I don't really use libxml-ruby. The way we deal with Hpricot's API (any differences between Hpricot and Nokogiri anyway) is a decoration system. You simply have to define modules containing the different functionality, and Nokogiri will mix the module in to every node. So defining a libxml-ruby compatible layer would be pretty easy. I just don't have any desire to do it. It doesn't solve any of my problems. :-\ > 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). I prefer the separate project solution. I'm not sure what bits of our code overlaps. I think our underlying C bits are too different. I'm all for sharing, but I like the project I have set up now. > 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). Sure. I don't mind having commit. If you'd like to hack on Nokogiri, I'd be glad to add you to our project. -- Aaron Patterson http://tenderlovemaking.com/ _______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
