[libxml-devel] [ANN] nokogiri 1.0.0 Released
aaron at tenderlovemaking.com
Wed Nov 19 23:05:57 EST 2008
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:
>> 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
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.
More information about the libxml-devel