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

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-06-03 22:13:21

It's worth noting that libxml2 is itself open source with what appears 
to be
Boost compatible license:

   http://www.opensource.org/licenses/mit-license.html

On Tuesday, Jun 3, 2003, at 20:21 America/Denver, Darryl Green wrote:

>> 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.
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost