On 05/09/2013 04:26 PM, Stefan Seefeld wrote:
In particular, it seems you aren't distinguishing between users and developers.
In our case there is overlap between them. Some users do not care about the implementation details. Other users want to use most of the library, but want to change certain aspects, e.g. adding their own binary XML frontend, or providing their own DOM. Having said that, I believe I have satisfied all the "pure" user requirements that you have mentioned so far.
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 ?
The problem you mentioned: "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."
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.
So if we want to offer both libxml2 and Xerces wrappers, this would result two separate Boost libraries?
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 was demonstrating how easy it would be to provide our own implementation of the well-established APIs (or their C++ equivalents.) It is possible to mix SAX and DOM from different backends, as I have indicated for libxml2, which is the only kind of mixing that I have argued for.
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 ?
No, the XML lexer is more an implementation detail. My proposal includes the whole range: XML lexer, SAX, XmlReader, and DOM. I have never argued that Boost.Xml should contain anything less. XmlReader will be ideal for Boost.Serialization. A clean C++ separation (builder pattern) between SAX and DOM would give us the flexibility to plug in different DOMs. This will be ideal for Boost.PropertyTree, which has its own "DOM". The separation will also allow us to plug in different SAXs, such as binary XML parsers. Come to think of it, the XML lexer could be useful for indexing (see Roger Martin's reference to VDT-XML.)