Boost logo

Boost :

Subject: Re: [boost] [GSOC] XML library of Boost
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2013-05-09 10:26:32


we are going in circles, which is in part because we still are talking
past each other.

In particular, it seems you aren't distinguishing between users and

On 05/09/2013 06:00 AM, Bjorn Reese wrote:
> 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.

Sorry, what problem is solved ?

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


You are citing out of context. Implementing multiple backends has many
benefits for *developers*, for example as it helps to guarantee that the
API isn't tied to a particular backend. It should not affect in any way
*users*, who will only use the boost.xml API (and library), without any
concern for any particular implementation choice.

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

It hasn't, and when expressed that way, I actually agree. What I don't
agree with is this:

> Start with an XML lexer. This simply returns the next token (start tag,
> attribute, data, etc.) when called.
> Put the XML lexer in a loop, and you get a SAX parser.
> Pair the XML lexer with a parent stack, and you get an XmlReader.
> Base the DOM parser on the SAX parser to create its tree. This is how
> libxml2 does it, and how it reuses the tree generator for parsing other
> formats such as HTML and DocBook.
> By default, I would provide our own tree, although this is not terribly
> important.

While the layering you describe pretty much matches a typical
implementation, this doesn't have any consequences for users, as these
layers can't be exchanged. You can't mix a layer from one backend and
combine it with another layer from a different backend. So why care, on
an API level ?

I believe your point was that you want to be able to implement only the
"XML lexer", but neither the SAX nor DOM APIs, and still be able to call
the result "boost.xml", yes ? I still think this is a bad idea.
Otherwise, as long as the full functionality is provided, I don't care
about the implementation, and in particular, whether someone will fancy
to rewrite it "natively" instead of building on top of existing
third-party libs.


      ...ich hab' noch einen Koffer in Berlin...

Boost list run by bdawes at, gregod at, cpdaniel at, john at