Re: [boost] [GSOC] XML library of Boost

Subject: Re: [boost] [GSOC] XML library of Boost
From: Bjorn Reese (breese_at_[hidden])
Date: 2013-05-09 06:00:45

On 05/08/2013 02:08 PM, Stefan Seefeld wrote:

> You are evading the question. A user may not even care how boost.xml is
> implemented, as long as the functionality is there. If I'm such a user,
> I don't want to be confronted with the question of what backend to pick.

Then create a 'boost-xml-standalone' package without dependencies, and
let the 'boost-xml' package depend on the 'boost-xml-standalone' and
'libxml2' packages. Problem solved.

Let me quote some conventional wisdom about external dependencies from
the discussion:

   "Then (s)he has to install the prerequisite libraries, as is custom
    with all software that is being used today."

> Right. But again, I think you are making life much harder than it needs
> to be for users. As a user I want to use the boost.xml library in my own
> project. Do you really anticipate there to be a bunch of different
> backends being offered to end-users to pick from, depending on what
> functionality he requires ? What a drag ! Just give him a a single

I thought that this was part of the GSoC proposal, which states:

   "Then I’ll define some APIs which boost.xml doesn’t support currently
    and map them to libxml2. Then I also want to add support for xerces."

I have not seen any complaints from your side about adding support for
Xerces.

Having said that, with the proper defaults, the user do not have to do
anything. Only if he wants to do something different does he need to
include another header, pass an extra argument, or whatever. This is
how the rest of Boost handles variation. Why has this suddenly become
much harder?

> library with easy instructions on how to call, link, and execute it.
> Being forced to look at  backends totally defeats the purpose of having
> an abstraction layer in the first place.

I am not sure that I follow you here. Why do the users need to look at
backends?

> What I'm saying is that, once you impose "our own implementation", you
> eliminate the majority of existing backends, including libxml2 and
> xerces, because they have their own. And so, to support such backends,

No, you have got it completely backwards. My proposal does not have this
limitation. Quite to the contrary, and in the case of libxml2 the
integration is even trivial. Please go back and re-read my proposal,
and pay attention to the builders.

With my proposal we get more flexibility, not less. For instance, we
can write a binary XML frontend, and have it generate a libxml2 tree.
This allows us to validate or transform binary XML with libxml2 even
though it is not supported by libxml2. It also allows us to convert
between textual and binary XML quite easily.