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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-06-03 09:04:47

Vladimir Prus said:
> William E. Kempf wrote:
>
>>> there is no such thing as the 'Gnu licence'. There is the 'GNU
>>> General Public License' (aka GPL) and the 'GNU Lesser General Public
>>> License' (LGPL). libxml2 uses neither, and its license is fully
>>> compatible with boost's license requirements.
>>
>> Maybe, but it fails the Boost Library Guidelines:
>>
>> "Use the C++ Standard Library or other Boost libraries, but only when
>> the benefits outweigh the costs.  Do not use libraries other than the
>> C++ Standard Library or Boost. See Library reuse (edit:
>> http://www.boost.org/more/library_reuse.htm)."
>>
>> 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. The
> effort to write a new library from scratch would be quite serious, and
> will result in anything tangible only after a lot of time. Unless
> somebody has really lot of spare time, wrapping existing library is the
> only way how XML support can be added in boost.

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.

-- 
William E. Kempf