On Mon, 17 Apr 2006 01:35:59 +0100, Sean Chittenden <[EMAIL PROTECTED]> wrote:
>> On the other hand, I'm not necessarily adverse to having some kind >> of 'easy' API built on top of the core library, if there was enough >> to it, and it was sufficiently 'easy', but then again that's >> probably for another (dependent) project. But in this sense I don't >> consider methods like 'first' and 'empty?' as easy - I consider them >> essential parts of the core library. >> >> Anyway, that's just me. Sean might have a different view...(?) > > And I do! The C library could easily include, mixin, or inherit bits > from a plain text ruby library. As bottlenecks and performance issues > are identified (or as time permits), the ruby library could be > converted to C. The `require 'libxml'` line should include the .so, > but if the .so includes additional ruby files, who cares... this'll > provide an easy way for us to prototype new APIs before they get > integrated into the core. > Okay, I've set this up in CVS. Basically, the C library is now xml/libxml_so, and 'xml/libxml' is a Ruby file that requires libxml_so, then goes on to make the modifications Mark and I put together. I'd still like to get empty? implemented in C at least but as you say it's a good way to get it in quick. What do you think to having an 'xml/libxml2' require as well, maybe lightly deprecating 'xml/libxml'? (Aside, I'll add the same setup on libxsl, to avoid the link errors when xml/libxsl is required without an explicit require 'xml/libxml'). -- Ross Bamford - [EMAIL PROTECTED] _______________________________________________ libxml-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/libxml-devel
