Hey Gareth and Boris, I'm pretty calm about the whole thing. It's been really super being part of the Xerces team for seven years - even if my total contribution hasn't been all that much. I do not have any ego at stake as to whether Xerces-P survives the chopping block.
If people want it around, then I think they should speak up. And it would be a big help to me if others would help maintain the bindings. But the swig bindings are beyond most Perl users (or Python or Ruby users too). They are all C++ - and pretty involved C++. To see if something breaks - it is now as simple as doing a make test-suite, and we should see all tests pass. If individual tests fail, they can be run manually to generate more output to indicate why they failed. Usually the problem is that some class header file changes, and some method has a new type signature and the library won't link. When that happens, the SWIG-generated C++ files need to be regenerated by running swig. So usually, it is pretty simple. What has created trouble for me in the past is upgrading to more recent versions of SWIG to gain new features... This has caused me to rewrite the interface definition files, and that often takes debugging time. But if we stick with a given SWIG version, creating a new release of xerces-p is as simple as rerunning swig and recompiling. As I mentioned last year, I would love to see the test-suite grow to include all the classes of the public Xerces API and all the methods. Right now, I'm guessing the coverage is less than 50%. This may be seen as a reason for keeping the SWIG bindings around. The Perl test harness is VERY helpful for unit testing - but of course I'm a Perl programmer... Again, I'm open to suggestions. Cheers, jas. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
