[libxml-devel] [ANN] nokogiri 1.0.0 Released

[Aaron Patterson]

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/