Re: MySQL ASIO library

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-03-04 14:15:35

[Sending this reply to list as opposed to personal email]

On Wed, Mar 4, 2020 at 3:39 PM Richard Hodges <hodges.r_at_[hidden]> wrote:
> On Wed, 4 Mar 2020 at 13:25, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
>>
>> On Wed, Mar 4, 2020 at 1:50 PM Richard Hodges via Boost
>> <boost_at_[hidden]> wrote:
>> >
>> > > Why just MySQL?
>> >
>> > Getting something useful released is more important than getting something
>> > perfect released.
>> >
>> > If Ruben has a ready-to-go solution for MySQL, why not make it available to
>> > users?
>>
>> Making it available to users is not the same as making it part of
>> Boost. Boost is known for general purpose libraries, as well as more
>> domain-focused solutions, but it is not a place for wrappers around
>> specific other libraries. Let alone, when the said libraries already
>> have C/C++ API.
>
> Boost also has mpi, regex, asio::ssl and python. What are these if not wrappers around common c libraries?

I'm not sure about Boost.MPI, but I thought it was not a wrapper of a
single library, but of a standard API that can be implemented by
different libraries. Boost.Regex is not a wrapper at all; it
implements regular expressions from scratch. asio::ssl is not a
library but a plugin for Boost.ASIO that provides one small piece of
functionality compared to the rest of the library. Boost.Python is
probably closest to an exception, although it is a binding to another
language (not a library), which arguably only has one C API and
implementation. Yes, there is CPython, but I don't believe it offers a
C API.

>> > It can always be complemented or extended with Oracle, SQLite, ODBC etc etc
>> > later.
>>
>> If the proposed library offers a stable and flexible API that can be
>> backed by multiple implementations then by all means - that would be a
>> very interesting proposal indeed. But the author has to demonstrate
>> that the proposed user API can in fact be supported by more than one
>> backend, so at least two backends need to be presented, and preferably
>> with guidelines and infrastructure for adding more.
>
> Mpi, regex and python would dispute this arbitrary restriction.

I don't think so, as per above.

> Boost suffers from a lack of contribution. Is there any value in making contribution difficult?

I don't think the amount of contributions by itself is the goal. There
has to be value associated with the contribution. I just don't think a
C++ wrapper of a specific library has enough value.