On Sun, 2007-10-28 at 22:41 -0400, Andrew Stitcher wrote: > [Resent due to lossage] > > I agree with most of Alan's thoughts, but see below. > > Alan Conway wrote: > > We use boost heavily in the C++ implementation, the question arises > > whether we use it in the public API. We do link with boost libraries so > > we will require boost runtimes to be installed regardless. > > > > There are 3 levels: > > 0 - No boost includes in public header files. We do not require boost > > developer package (header files) to be installed. > > > > 1 - Private/implicit use of boost. We do require boost-devel headers > > installed for Qpid developers but we don't require the user to know > > anything about boost or even be aware we're using it. > > > > 2 - Public use of boost: we include boost types in the public API. > > > > I've been convinced that 2 is bad as it ties us to boost for future > > source-compatibility. We have some work to do to eliminate > > boost::shared_ptr from the current API but I think it's reasonable and > > all the client API needs can be met without it. > > > Completely agree here, but I'm not convinced that there is so much > difference. As the difference here is that you could in theory replace > the boost implemented features with some other implementation, but you > will still structurally depend on the boost headers.
The difference to me is whether or not we can change the impl in a source-compatible way. In case 1) user would never have to #include <boost/...> headers or refer to boost::... symbols in order to use Qpid, so we could replace boost without breaking existing code. Another difference is that in case 1 we never have to document the use of boost types. > > I can see the attraction of 0, but I don't think it's practical. The > > Session API uses keyword arguments to great effect. [snip] > > > I agree that keyword arguments are convenient, but I'd like there to be > a version of the API that doesn't require them, ie I'd much prefer them > to be a convenience layer over a simpler API that doesn't require boost. > That's certainly possible. I have already been thinking of them as a layer over the binary API that we maintain for binary compatibility, but this could also serve as a "boost-free" user API. > I hope that this makes sense - I've just got of a plane across the > Atlantic so I may not be at my best! It does indeed, we'll talk more when the jet lag wears off :)
