> From: William E. Kempf [mailto:[EMAIL PROTECTED] > Vladimir Prus said: > > William E. Kempf wrote: > >> > >> If a submitted library required libxml2, I'd personally > vote no. If > >> the interface was supposed to be portable to other backends, I'd > >> probably still vote no unless at least one other backend > was included > >> as proof of concept. It would still be nice to have a > Boost supplied > >> backend, probably via Spirit, but so long as I was confident that I > >> was not tied to any specific non-Boost library, it wouldn't matter > >> that much. > > > > I tend to disagree here. Writing XML library is not easy, > and libraries > > like expat and libxml2 are already here, working and debugged. ... > > Careful with what you disagree with. I stated that it would > still be nice > to have a Boost supplied backend, but I didn't state this was a > requirement. What I think *is* a requirement is that any > wrapper library > not be tied to a single backend, and I personally believe that what > follows from that is that the submission must have at least 2 > referenced > backends for proof of concept. Note that this is precisely what > Boost.Threads does, for instance.
I agree that the interface shouldn't be too tightly bound to the underlying library. imho the interface Stefan has written isn't tightly coupled to libxml2 in the sense that the interface would need to change or be a poor fit on some other library. However, the implementation (and efficiency) of the wrapper is certainly aided by the libxml2 library interface needing only a very thin c++ veneer, and libxml2 being very comprehensive in its facilities. As a user, I had already decided to use libxml2 and wrap it when Stefan posted. The decision was based on code size, performance and features of the xml lib. I had already looked at using Spirit, and found the example xml parser too slow in comparison to other parsers, in particular expat and libxml2. To provide the same facilities as libxml2 requires considerably more than just a parser - performance issues aside. I can't think of a good reason for wanting to apply stephen's interface to another underlying xml lib, until or unless there is a better performing xml lib than libxml2. I would suggest that the portability (or otherwise) of Stefan's library could be assessed/reviewed without necessarily requiring another implementation for which there would likely be no users. This is a bit different to threads, (warning: Alexander bait) where there is clearly a requirement to use the native platform library facilites, and these facilities differ significantly. There isn't really that much variation in how one presents xml using a dom, sax and xpath based interface - it just needs a c++ "language binding". Regards Darryl Green. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost