[libxml-devel] [ANN] nokogiri 1.0.0 Released

Charlie Savage cfis at savagexi.com
Wed Nov 19 15:09:06 EST 2008

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 much
> time.  

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 

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/libxml-devel/attachments/20081119/311ee7c6/attachment-0001.bin>

More information about the libxml-devel mailing list