Michael Marcin wrote:
Stefan Seefeld wrote:
Phil Endecott wrote:
Aiming for the minimum overhead in your libxml2 wrapper is a valid objective. But perhaps in that case you should be selling this as a "C++ wrapper for libxml2", not as a "Boost XML library"? I would have thought that a largely backend-independent (or self-contained) library with STL-like interface would be more "Boost-compatible". What about my proposed interface is libxml2-specific, prompting you to call it a 'libxml2 wrapper' ?
If you are designing the interface to minimize overhead using a libxml2 backend then it will likely incur undue overhead using some other backend and thus make the library essentially viable only with a libxml2 backend.
I don't follow that argument. Minimizing overhead doesn't mean I try to keep as close as possible to the libxml2 API, but instead, I allow for enough latitude in the spec to adjust to backend-specific handling. That appears to be a common theme in standardization: Be specific enough to be actually useful for end-users, and flexible enough to make implementers happy.
Making the wrapper as thin as possible, yet making the API itself backend-agnostic (and thus allow it to be reimplemented with other backends) is part of the balance I was talking about, too.
In my experience until I actually have 2 or more dissimilar backends implemented the interface is not implementation agnostic.
That's a fair point. I'm not saying the API actually is implementation agnostic. But I try to. I would certainly appreciate if others tried to provide alternative bindings, so we can compare. May be it's a little early to do that, though. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...