Maciej Sobczak wrote:
Beman Dawes wrote:
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.
Which raises a series of new questions. Now, the SOCI library provides a common interface that is independent from the particular server technology (well, as far as SQL dialects go...). The user of the library can select any supported platform by naming the factory object at the connection time:
Session sql(oracle, "some parameters");
Above, oracle is a name of the factory singleton that is used by Session to create concrete instances for relevant backend objects.
For the last three releases we have focused on getting as many working backends (which translate into many factories) as possible, which makes SOCI practically useful. The word "practically" is crucial here, because this is where the possible standardization process can get tricky. The standard was always very careful not to impose any constraints that would unnecessarily limit the implementation possibilities and this will have to be applied here as well. I understand that the committee will be reluctant to put any obligation that the implementation must provide this or that backend factory, which in reality will mean that vendors will be able to provide no factory at all, or just their favourite, so that there will be environments that don't have any single factory in common. Just for the sake of practical example: Microsoft will provide odbc and/or mssql factory, GNU people will provide mysql and postgresql and the portability of final applications is gone. In fact, I see three possibilities:
1. Define backend interface in a way that allows vendors to provide standard-compliant backends. From the interface point of view they will be replaceable, so that two vendors will be able to provide, let's say, the oracle factory, but that still means that the portability of final programs will be severely limited because of the strong dependency on the availability of any given factory in the target environment.
2. Define some "reasonable" set of backends (the current set in SOCI is reasonable) and oblige vendors to implement all of them. This is completely unrealistic for political reasons.
3. Decouple the low-level mechanics even further and state that the way to choose the backend is implementation-defined and external to the C++ itself. This basically brings us to ODBC, which we might therefore standardize right now.
How about this: 4. Same as (1), but also require one generic backend, say "default_backend", with a portable set of parameters that are really just hints. Vendors could supply additional backends if they desired. The details of default_backend are not otherwise specified. The idea is that those who care more about portability than performance can use default_backend, while those who want the attributes of some specific backend can specify it. They then have to obtain an implementation of that backend if they move to another platform.
My point is that even though I really see SOCI as a very practical tool for people that need practical solutions, I don't see how it might get ever standardized. You just cannot standardize that the library has to support Oracle/MySQL/whatever and if you don't standardize it, there is very little left.
I'll defer commenting on that until I've studied the SOCI docs a bit. Thanks for your interest in Boostifying SOCI! --Beman