Re: [boost] [GSoC] Boost.XML

Subject: Re: [boost] [GSoC] Boost.XML
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2010-03-23 08:34:09

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...