On Thu, 2013-06-20 at 18:19 +0100, Gordon Sim wrote:
> ...
> > I've prepared a change and review that encompasses this work and a
> > little more:
> 
> The 'little more' here refers to hiding the entire qpid::client API. 
> That is a significant enough change that it needs to be explicitly 
> brought up in its own right, not bundled in with the removal of the much 
> more obscure QMFv1 stuff.

I actually thought this was uncontroversial because we've indicated it
is a deprecated API for so long. Is there still actually anything that
users can't do with the messaging API that can do with the client API?

> 
> I'm not clear on what the immediate benefits of this are (the code is 
> all still there, its just that the headers are not installed), but the 
> potential impact to some users is certainly significant. I've been 
> encouraging people to move towards qpid::messaging, but this seems 
> drastic and sudden for the 0.24 timeframe.

The benefit is precisely that we will no longer export API headers that
we don't support. I think this is somewhat important to robust
modularisation so that we can be sure that no code being moved out of
the tree accidentally depends on non supported APIs.

The code is there because it will still be used internally.

> 
> If we want to make a clear signal regarding deprecation, what about 
> having the qpid::client headers installed only through a separate make 
> target (e.g. make install-deprecated). That way users still relying on 
> the API get a clear warning. That option can then be removed in the 0.26 
> or whatever.

The current install targets don't work like that they copy everything
under cpp/include to the install area directly.

We could add an extra install target say "install-deprecated" which goes
and picks out the deprecated headers from where-ever they are in the
tree and copies them to the install area, but it seems like a lot of
work.

In the end I agree with Ken that we should loudly announce all this
stuff is going to be gone in 0.26 and remove it from trunk immediately
after we branch 0.24 for beta.

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to