Firstly to say that I'm currently on holiday under a qpid curfew :-) so I can only sneak in a quick response at the moment, I'll try to give some proper answers to questions posed in this thread later on in the week.
On Gordon's --mgmt-qmf1=false I "thought" those broker flags only actually related to "push" messages sent from the broker, so that"s things like heartbeats and the broker "data push" that can be subscribed to, I'm pretty sure that the request/response stuff is driven by the address used, for example qmf2 uses qmf.default.direct or qmf.default.topic, for qmf1 there's another address qpid.management??? - I'd need to check. Anyway I think that's how you'd select between QMF2 and QMF1 for request response type things. The python APIs do this transparently under the hood. there's been some talk about ObjectIds, now it is true to say that V2 ObjectIds comprise a Map that may have some meaningful names, but the qmf2 API spec says that they are supposed to be opaque, the python lib tools have definitely "interpreted" them, but I'm not personally convinced that that's a great idea. I've certainly avoided interpreting them in anything I've done with QMF. To be fair it is all a bit ambiguous give that the names in the protocol suggest something, but as I say the QMF2 API doc definitely says opaque, but then again the API seems to have fallen against the wayside rather, which is kind of a shame. One comment for Bill, the GUI that I put together has been mentioned, it's worth taking a look at, in particular it's not just a GUI, it's backed by a Java implementation of the documented QMF API, so if your Web server is Java based that might be more convenient to use that a python API. There is also a Rest API for QMF and a JavaScript API that is backed by the Rest API. One last thing, there is some discussion beginning about the future of management, the eventual intention is to move away from QMF towards a new AMQP management API, however that is in the very early stages so at the moment QMF is the only game in town for C++ broker management. There are a few of us very keen to make sure that transition to the new API is as painless as possible, but as I say it's very very early days and is mainly said to try to ensure that you bear it in mind with your application. I'd very definitely avoid QMF1 though QMF2 is a better bet. I'll try to give some slightly deeper responses later in the week, HTH, Fraser On 1 Apr 2013, at 18:35, Bill Freeman <[email protected]> wrote: > On Mon, Apr 1, 2013 at 12:21 PM, Gordon Sim <[email protected]> wrote: > >> On 04/01/2013 05:06 PM, Bill Freeman wrote: >> >>> since I have a dog and pony show coming up shortly, do you >>> know how to get the existing qmf.console stuff to send my updates as V2 >>> (session has rcvObjects True). >> >> One option might be to turn v1 off at the broker... --mgmt-qmf1=false to >> qpidd. I don't know hoe effective that will be, just a suggestion. >> >> Thanks. I may test with that, but for production I can't be sure that > some department that I don't know about is using a V1 only tool. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
