On Dec 8, 2008, at 2:09 AM, Charlie Savage wrote:
Hi everyone,
Over the last month there I've put out a series of libxml 0.9.x
releases with the aim of reaching 1.0 by the end of the year.
These releases have made a number of improvements to libxml-ruby,
including:
* Fix all known segmentation faults
* Much better documentation
* Much better support for encodings
* Cleaned up namespace support
* Closing off almost all bug reports, patches and features requests
* Ruby 1.9 support
* Heavily refactored code base
I think the bindings are now in great shape and worthy of a 1.0
designation. But before we get there, can everyone upgrade to the
latest 0.9.6 release and report back to the Ruby forge tracker
(http://rubyforge.org/tracker/?group_id=494) any issues they run into?
And thanks to everyone for reporting issues over the last month.
Charlie,
Thanks for your hard work on this, it's great to see libxml
progressing so quickly. Before 1.0 I think there is one item that
needs a serious overhaul. Right now the default error handler is
VERBOSE_HANDLER which just writes out error messages to STDERR. This
makes it difficult to trap errors since I don't think it's always
clear from the return value of method what type of error was
encountered. I propose using either some type of exception hierarchy
with specific exceptions as appropriate (e.g. WellFormednessError,
DTDValidationError, etc.). If this is not feasible on a short time
scale I think at a minimum the current error handling should be
refactored to stash the current error message in the Error object on
Parser. Methods could then raise exceptions for error (or in the
interim, return nil) and the caller could get the message back.
I'd like to see what your thoughts are on this, I'm happy to provide
the first pass at a patch that implements this behavior. Error
handling right now is a major obstacle for me.
--Paul
_______________________________________________
libxml-devel mailing list
libxml-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/libxml-devel
