RE: [boost] Re: Re: an XML API in boost

From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2003-06-03 21:21:52

> From: William E. Kempf [mailto:wekempf_at_[hidden]] 
> 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.