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. I can see the attraction of 0, but I don't think it's practical. The Session API uses keyword arguments to great effect. This is at level 1 - the user can type session.subscribe(queue="foo") without knowing that we use boost to make it work. There is no way we can rewrite boost's keyword argument stuff and without it Session is unusable as an API. Given that, it makes no sense to re-invent the wheel for other implementation details where boost provides a ready-made solution. I'd vote for a public API that requires no explicit knowledge or documentation of any boost classes or concepts, but that qpid headers may #include boost headers for private or implicit implementation details. Cheers, Alan.
