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?
Hi Andrew,
That's not actually the argument, certainly from my perspective, indeed
from a personal perspective I've only ever used qpid::messaging in anger
and have always stated quite vigorously to anyone who will listen that
they really really need to move to qpid::messaging because qpid::client
has been deprecated like, forever.
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.
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.
Thoughts?
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
