Nicola Musatti wrote:
Maciej Sobczak <prog <at> msobczak.com> writes: [...]
I would like to stress that the ODBC support was our important milestone that now allows us to claim a quite extensive coverage of existing database technologies. With this in mind, SOCI becomes even more serious and our roadmap for the nearest future is to bring the library to the state that will make it a valid candidate for inclusion into Boost. We will therefore welcome your guidance and suggestions w.r.t. Boost compliance.
Note that up to this release, the library was deliberately developed without any external dependencies, so there are obviously wide areas where Boost might be applied within the library itself (example: intrusive pointers to manage some refcounted objects). This is easy. The more difficult part is the library interface and its general philosophy.
The last time this topic was discussed, it was hoped that the outcome could be a proposal to be included in the standard committee's TR2. Even though that deadline has passed proposing a library for inclusion in the standard is certainly a worthwhile objective; is that something you want to pursue with SOCI?
As a long-time C++ committee member, I can say with certainty that the committee will be *very* interested in a Boost Database library. Please don't worry about whether it is for TR2, TR3, or something else. Just proceed with getting SOCI ready for a Boost formal review, and work on the assumption that if Boost users find the library useful, it will be proposed for eventual standardization.
I'm asking because I think that the answer may influence interface choices, e.g. to simplify support for single backend implementations or to limit use of Boost libraries to those accepted in the TR's.
For the public interface, I think it is appropriate to depend on any Boost library accepted for TR1,TR2, or C++0x. As far as the internal implementation goes, that is pretty much up to the library's implementors, IMO.
As I already mentioned in a previous discussion I believe that a distinction should be introduced between core DB access functionality and higher abstractions such as the object/relational mapping, especially in view of a possible standard submission.
The C++ committee's LWG tends to prefer that a library expose the lower-level functionality used to build higher-level abstractions, particularly when the library is implemented by calls to third-party API's. Speaking of third-parties, requiring the user to include headers specific to particular back-ends sounds controversial, although I haven't studied SOCO's interface yet so don't know that for sure. --Beman