On 18/06/13 23:30, Ken Giusti wrote:
Folks,
There's some old QMF-related code in our repo that appears to be quite dead.
If said code is in fact "pushing up the daisies", I'd like to see removed prior
to the 0.24 release.
First, there's stuff that I'm almost certain is stone cold dead. AFAIK, this
shouldn't be used by anyone. It certainly isn't being maintained.
Specifically:
qpid/extras/qmf/src/py/qmf2-prototype - experimental stuff done while
developing QMFv2.
I suspect that you are correct that it's not used by anyone, though I'd
quip that's because as a community we've not done a terribly good job so
far of providing a cohesive unified approach to AMQP management - though
of course anyone who reads my posts knows my views on that already :-)
FWIW I don't tend to use python for anything more than tinkering so it
won't have an operational affect on me, however I will say that I'd got
something of a soft spot for that particular bit of code, because it's
the only bot of QMF2 other than the Java stuff that I put together that
actually follows the only publicly published QMF2 API :-) so I felt a
certain sense of strengh in that... For better or worse I actually far
prefer that to the qpidtoollibs library that sprung up to replace the
original QMF1 library for the standard tools, qpidtoollibs to my eye
feels like it "organically evolved" a little - sure it's made a big
difference to qpid-config et al but it feels less of a structured API
than the one in qmf2-prototype.
It's all a bit moot of course and if nobody is using it I won't stand in
the way, though perhaps we should leave it rotting in a gibbet to
provide a lesson from history that we must try harder next time :-)
You see - any time anyone mentions QMF2 I end up going off on one :-D
qpid/cpp/{include,src}/qmf/engine - an attempt to re-write QMFv1 in C++.
qpid/cpp/bindings/qmf - multi-language bindings for the above 'engine' code
Seems fair to kill this.
There's other stuff that appears to have shuffled off the mortal coil, but may
simply be in a deep coma [1]. These would be the old QMFv1 agent and console
libraries:
qpid/cpp/{include, src}/qpid/agent
qpid/cpp/{include, src}/qpid/console
Anyone still using these libraries?
I'm not, but I wonder if these need the "fair warning" approach that
seems to have been fairly well supported in the discussions around
removing automake and moving to cmake. Given all of the discussions that
exploded after the initial abortive attempt to rationalise the QMF1
stuff in the asynchronous python API and the realisation that it didn't
actually work for QMF2 and nobody had really noticed (most likely
because the broker Agent pushed both QMF1 and QMF2) I have a gnawing
feeling that there "just may" be more people using QMF1 than we
suspect/hope.
So how about
a) A few more warnings like this shouted out on the user list.
b) disabling it from building as the default and requiring an explicit
option
c) updating the doco to say it's in the departure lounge and will be
euthanised in 0.26
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
