----- Original Message -----
> From: "Fraser Adams" <[email protected]>
> To: [email protected], [email protected]
> Sent: Wednesday, June 19, 2013 3:04:08 PM
> Subject: Re: QPID code reorg/cleanups - please read.
>
> 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 :-)
>
I agree that it's a useful reference. It would still be easily available on
the past branchpoints, should we need to reference that code.
> 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
>
I'm agree with this specifically regarding the qpid/agent and qpid/console
code. It would be ideal if we could get that code to log errors or link
warnings for 0.24, just to make it hard to ignore.
> Thoughts?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
