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.