qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: QPID code reorg/cleanups - please read.
Date Wed, 19 Jun 2013 19:04:08 GMT
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message