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
> 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.
>
>
