On 2014-07-23 15:13, Michael Shepanski wrote:
On 23/07/2014, at 10:54 PM, Roland Bock
wrote: On 2014-07-23 14:09, Michael Shepanski wrote:
Also I'm thinking that my approach of having separate backend libraries is not right. The idea had been that a user decides which backend library to download and build, but that is not going to be happening a boost context. Everything should be in the "quince" library, every user downloads it all, and its build script decides which components to build.
Hi Michael,
There's also MySQL and MariaDb and Oracle and TransactSQL and Firebird and BerceleyDB and I don't know how many else, but a lot. To me it does not sound like a good idea to have all backends in one giant library. I don't have any strong opinions about this, and I'm happy to go with the conventional approach -- as soon as I know what that is.
Taking your lead and daring to imagine a future with quince backend code for a great many DBMSes, I ask: what do you propose? Would there be a separate boost/libs/quince_xyz for each DBMS xyz?
Also, what disadvantages do you see in the "one giant library" approach (assuming that its build script chooses which parts to compile, based on the presence of third-party libraries).
I guess that you would not want to maintain the backends for the umpteen databases. I don't know what the best approach is. Maybe you provide backends for the most popular databases and let others provide backends for the rest? I don't think that there is a precedent for this situation. Personally, I would prefer the individual repositories. It makes it easier to distribute the work load and you would not have to decide which databases to include in the main repositories and which to keep out. It would therefore also emphasize the vendor neutrality of the main library. Regards, Roland