On 03/23/2010 05:14 AM, Ilie Halip wrote:
I'm curious to see what Ilie is taking from this discussion. Hopefully we're not scaring people away ;)
No, not really - though I do admit the talk around here has been a little confusing. :) I haven't had time to reply yesterday, sorry.
I'm not sure this kind of project would have enough complexity to actually work on for more than 2-3 weeks. Except for the actual calls to the underlying XML parser, there are little modifications to be done (API change to support multiple backends, maybe detecting them at runtime?, setting options if needed).
Let me write down a little "shopping list" of things that I consider worthwhile doing, based on the existing boost.xml sandbox project: * Add tests, to provide better coverage (different string types, different input; test error reporting, etc.) * Add examples, to show the different features * Add at least one new backend (implementation), and make any required modifications to the API to support this abstraction. (I made every effort to keep the current API agnostic to the backend used, but since I didn't really attempt to work with something other than libxml2, there may well be aspects where the backend "leaks" through.
There will be problems when the backend parser doesn't support a necessary feature (like TinyXML not supporting validation), or implementation details making it difficult to use (like MSXML requiring COM, which means CoInitialize() calls on each thread that's using it), or those with enough features have huge binary packages.
I don't expect the result of the additional backend binding to necessarily be very appealing. After all, there is a reason why I chose libxml2: At the time I found this to be the best choice. The main incentive for this work is to make sure the backend *may* be switched without affecting the API.
A first step would be researching different 3rd party xml libraries, and make some choices. And I fear it's me who has to make those choices, because I have to write the proposal. Any hints in this direction are greatly appreciated.
Yes, doing this research should be part of the GSoC project. One rather obvious candidate seems to be Xerces (http://xerces.apache.org/xerces-c/). It has been around for a long time (as long as libxml2), and thus can be assumed stable and feature-complete. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...