I think most of my concerns, while not fully addressed, are nearing to a
semi-satisfactory state. I still have concerns about binary
compatibility, and I don't think the project team has adequately
presented an answer to the following two questions:
1) how will we alert users/developers to the dangers (binary
compatibility dangers, that is) of using this library
2) how will this project fit into any long term strategy with
respect to C++ standards conformance
The lack of (or appearance thereof) a long term strategy with respect to
C++ standards conformance is something I find deeply unsettling.
The fact that libraries compiled against this library will be
incompatible with libraries compiled against other "default" libraries
is only moderately unsettled -- but the fact that developers will have
no way to apriori identify what the compatibility issues between
"middleware" libraries is a serious shortcoming, and one that I think
should be fixed if we're going to make any kinds of promises here.
One way the team could help address my concerns would be to declare the
*source code* interfaces to be Committed, but avoid granting that status
to the binary interfaces. (And yes, the library has binary interfaces
-- I'm not talking about the C++ ABI here, but the combination of ABI
from the compiler and binary interfaces that result from compiling this
library's header files.)
Another mitigating approach would be to request/require that middleware
developed on top of this library somehow name their libraries (perhaps
by placing them in a directory) so that the linkage compatibility issues
are made explicit. This could also help address the situation when we
need (as I suspect we will) to change the binary interfaces when a new
version of the library is included/shipped.
Another approach might be for other projects (KDE) that need this
library perhaps a solution involving autoconf style pkg-config to
specify compiler options, along with a contract for the use of the
interfaces, might be another approach.
In any case, I'd like to request that the timeout for this case be
extended until the next public PSARC meeting (i.e. Sept. 10).
Its possible that the best solution here would be to derail and
subsequently approve the case, so that the ARC can supply an opinion
requesting Sun mgmt to fund additional work to address the problematic
gaps here.
-- Garrett
