On Fri, 2013-06-21 at 11:03 +0100, Fraser Adams wrote: > On 20/06/13 21:46, Andrew Stitcher wrote: > > 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? > > ... > However...... as I mentioned in my other mail corporate IT Departments > are very often disinclined to "keep up with the times" and other > business priority pressures can mean a degree of stagnation that can > only get loosened by a "clear and present" imperative. So just saying > it's deprecated doesn't always focus the mind, but actually giving a bit > of a kick usually starts to do the trick.
But if they don't upgrade then the removal has no affect anyway, we're not removing support from anything already deployed. If they decide to upgrade past the removal then they will have to modify their code. I honestly don't see how this could be changed - it's already deprecated, unless we keep it forever there will always be a point at which they will have to modify their code on upgrade. > > On a related aside on the subject of "is there anything users can't do" > I know of at least one user who has stuck with qpid::client because of > the fine level of granular control. He was pushing the performance > boundaries and couldn't find the tweaks necessary in qpid::messaging and > address strings. I guess that's an edge case, but if we're euthanising > qpid::client it might be nice to publish back to back performance > metrics and help to ensure that users can get the most out of Qpid. As a > general thing it'd be nice to have a performance tuning section in the > docs, there's been a few threads on sessions vs connections lately and > things like prefetch etc. can seem a bit of a black art and tweaks for > small messages vs large messages are likely different. The performance and documentation aspects are very real concerns, I agree. It would be useful to know the precise tweaks that were needed that could only be applied using the deprecated interface. Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
