[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. > 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. > > 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. I hope that this makes sense - I've just got of a plane across the Atlantic so I may not be at my best! Andrew
