Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?

Subject: Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-14 02:46:44

On Tue, Dec 14, 2010 at 3:18 PM, Artyom <artyomtnk_at_[hidden]> wrote:
>
> - Performance is the primary goal - make fastest possible
> Â SQL connectivity as possible
> - Transparent connection pooling support
> - Transparent prepared statements caching
> - Dynamic DB modules loading and optional static linking
> - Full and high priority support of FOSS RDBMS: MySQL,
> Â PostgreSQL, Sqlite3
> - Support as many  RDBMSs as possible via cppdb-odbc bridge
> - Simplicity in use
> - Locale safety
> - Support of both explicit verbose API and brief
> Â and nice syntactic sugar
>

How is this different from SOCI and why should I use CppDB over SOCI?

>
> Boost Interest
> --------------
>
> Currently I'm think whether should I boostify it,
> release it under BSL (currently it is LGPLv3) and
> submit it for formal review in boost or shouldn't I?
>
> Why do I ask, not because I'm thinking it is not good enough
> but rather because I feel that the "boostification" effort
> would be wasted at this point.
>
> For about half a year ago I had submitted a Boost.Locale for formal
> review, I use it under other namespace as part of CppCMS project all the
> time and in fact I receive most request and bug reports for Boost.Locale via
> CppCMS project and not via CppCMS.Locale so basically I have
> to handle two projects and synchronize between them all the time,
> and Boost.Locale is still stuck in review queue.
>
> So does it worth the effort?
>
> So before I do any steps forward may be it is better to
> make sure it gets (or even passes the review) and then
> boostify the library (which can be done very easily).
>

I'd say, it would be good to have a Generic Storage library that
abstracts the details of whether it's being saved to a file, to a
database, or to some other service in Boost. This way generic
algorithms that deal with stored objects/data can be implemented and
have "containers" or "silo's". Also, this way, anybody can adapt their
storage client libraries to this Generic Storage API (if it's ever
invented or agreed upon).

That said, I'd really not like to use code that is anywhere near the
GPL in all my projects. If releasing under the Boost license is an
option for you, I think that would be the single thing that I would
expect for anything being submitted for review to Boost. As for me,
I'm not really satisfied with having to deal with niche libraries
being made part of Boost (i.e. in this case the niche is database
access) when there's a much more generic problem that needs solving
(specifically, the abstraction of storage).

If I'm interested is another question, and the answer to that would
be: if you can show that your library is better than SOCI, then I
might be interested in using it -- but I'm not touching code that is
anywhere near the LGPL or the GPL for that matter if I can help it.

Thanks and I hope this helps.

-- 
Dean Michael Berris
deanberris.com