Re: QPID code reorg/cleanups - please read.
On Tue, Jun 18, 2013 at 6:30 PM, Ken Giusti kgiu...@redhat.com wrote: Justin - would it be possible to push back the start of Alpha? I imagine removing files could potentially affect distro stability, wouldn't want that to happen in Beta, right? Yes. I'll retarget the Alpha for the middle of next week. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proposed removal of qpid::client API (was Re: QPID code reorg/cleanups - please read.)
Good point Bill - I've created a JIRA to cut the console over to the messaging api: https://issues.apache.org/jira/browse/QPID-4945 Though, technically, I don't think we can easily remove the old client API from the _python_ client. IIRC, the new messaging api depends on it. - Original Message - From: Bill Freeman ke1g...@gmail.com To: users us...@qpid.apache.org Sent: Friday, June 21, 2013 1:08:29 PM Subject: Re: proposed removal of qpid::client API (was Re: QPID code reorg/cleanups - please read.) On Thu, Jun 20, 2013 at 4:46 PM, Andrew Stitcher astitc...@redhat.comwrote: 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? Depending on how you define users and do, yes. The python QMF console.py library uses the old API, and I use the console.py library. I don't actually touch the underlying old API, so a replacement python console using the Messaging API that provides the same interface to my code would leave me happy. I don't know whether that can be done with the Messaging API or not. But until there is such a replacement, I'd object to removal of the API (as opposed to removal of the documentation, which, from my perspective, is already gone). Bill -- -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proposed removal of qpid::client API (was Re: QPID code reorg/cleanups - please read.)
Not to forget that the WCF project also links to qpidclient. Would the proposed changes retire WCF as well? -Chuck - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proposed removal of qpid::client API (was Re: QPID code reorg/cleanups - please read.)
On Fri, 2013-06-21 at 14:27 -0400, Chuck Rolke wrote: Not to forget that the WCF project also links to qpidclient. Would the proposed changes retire WCF as well? I don't think so - the WCF build is entirely internal to qpid and the header files are still present internally (after all the messaging API itself depends on the client API internally). So since WCF isn't dependent on the exported header files I think it'd still be ok. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: proposed removal of qpid::client API (was Re: QPID code reorg/cleanups - please read.)
On Fri, 2013-06-21 at 14:02 -0400, Ken Giusti wrote: Good point Bill - I've created a JIRA to cut the console over to the messaging api: https://issues.apache.org/jira/browse/QPID-4945 Though, technically, I don't think we can easily remove the old client API from the _python_ client. IIRC, the new messaging api depends on it. Can we be really careful about our use of words here. We can't remove the *library* dependency here (and there is no current proposal to do this) but the python client has no API dependency on the old client API. In other words: The swigged libraries do not need us to ship any C++ header files let alone the obsolete client headers files. *There is no proposal to stop shipping the qpid client library functionality where it is internally used by other libraries with supported APIs.* Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: QPID code reorg/cleanups - please read.
On Wed, 2013-06-19 at 15:30 -0400, Andrew Stitcher wrote: On Tue, 2013-06-18 at 18:30 -0400, Ken Giusti wrote: Folks, There's some old QMF-related code in our repo that appears to be quite dead. I've create a JIRA to track this work: https://issues.apache.org/jira/browse/QPID-4940 I'm in the mood to remove lots of code from the tree ;-), so I'll prepare a change for review and we can have a lighter tree soon. I've prepared a change and review that encompasses this work and a little more: https://reviews.apache.org/r/12006/ Code changes: https://github.com/astitcher/qpid/commits/remove-old-api JIRAs: https://issues.apache.org/jira/browse/QPID-4940 https://issues.apache.org/jira/browse/QPID-4941 https://issues.apache.org/jira/browse/QPID-4942 I really like some of the implications of this work - specifically that it really tidies up the header files that we export to be installed for our APIs. I think this is very important for some of the suggested Qpid modularisation work going forward as it exposes a much cleaner interface. Any omments etc. please make soon on the review (or on this email thread) as I intend to push it to trunk for the 0.24 time frame. Thanks Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: QPID code reorg/cleanups - please read.
- Original Message -
From: Fraser Adams fraser.ad...@blueyonder.co.uk
To: dev@qpid.apache.org, us...@qpid.apache.org
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: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
--
-K
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
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 :-)
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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Re: QPID code reorg/cleanups - please read.
On Wed, 2013-06-19 at 20:04 +0100, Fraser Adams wrote: On ... 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? In this case, I think that we should remove it preemptively. The discussion that Ken linked to was from January 2012 and the consensus then was along the same lines as his proposal (at least the way I read the consensus) with no dissent. I'd say that is enough warning. In the case of autotools - cmake we know that everyone was affected, and cmake had some catching up to do, so caution was sensible. In this case as far as we can tell no one is affected! In any case we are using source control and can revert the removal if we really have to. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: QPID code reorg/cleanups - please read.
On Tue, 2013-06-18 at 18:30 -0400, Ken Giusti wrote: Folks, There's some old QMF-related code in our repo that appears to be quite dead. I've create a JIRA to track this work: https://issues.apache.org/jira/browse/QPID-4940 I'm in the mood to remove lots of code from the tree ;-), so I'll prepare a change for review and we can have a lighter tree soon. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
QPID code reorg/cleanups - please read.
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.
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
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?
Justin - would it be possible to push back the start of Alpha? I imagine
removing files could potentially affect distro stability, wouldn't want that to
happen in Beta, right?
[1] http://qpid.2158936.n2.nabble.com/QMF-and-Broker-Management-td7151372.html
--
-K
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
