Seeing that no one else has responded, I take as my cue to raise a red flag. I haven't talked to Dan about this, but I'm going to go out on a limb and say, that after following this project for many years now -- not to mention personally working to revitalize it TWICE, I've come to the conclusion that there may be something fundamentally wrong with its design. For some reason there have always been segfaults, and no one can seem to get rid of them all. Unfortunately, I'm not a C coder, so I can't really assess this from a technical standpoint, but only as as the "hands-off" project manger/assistant-manager role I've maintained, and as a user. While the library works fine in many cases, there seem to be enough problem cases that the library can't pick up general traction. Perhaps others can fill in on the technical difficulties and the breadth of these issues.
While problems could be arising from libXML2 itself I suspect that it is not generally the case, which makes me wonder how libxml-ruby is actually designed under the hood. Wouldn't it makes sense simply to map the libxml2 api to the Ruby C extension essentially one for one, and then write everything else as a pure-Ruby "Ruby-way" wrapper around that? Maybe this is how it is designed, but I can't really imagine it because I would expect it to work fairly flawlessly if that were the case. But like I said I'm not a C coder, so I can say for sure. I just wanted to put my thought out there and get some feed back on this. So I think at this point, the questions must be asked: How serious are these continuing issues? Are they fixable? And should the current code be abandoned and this project completely re-written from the ground up instead? -- Or am I interpreting the error reports and the otherwise relative silence on this list incorrectly? T. _______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
