qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Questions from a novice
Date Tue, 02 Apr 2013 17:48:44 GMT

> WebSockets in the browser is event based.  You register a callback for a
> new message.  You send a message either because the user clicked something,
> or because a timeout expired.  So threads aren't forced by WS.
Yeah I realise that, my point was that with the AJAX/REST approach everything was event driven
JavaScript side too. I'm not disagreeing at all that ultimately WebSockets are the way to
go, as I say it was mostly down to a combination of lack of familiarity and something of a
lack of maturity of WS. As you point out the latter is decreasing with good support in Chrome,
FF, Safari and recent IE. It's definitely on my TODO list, but hasn't been a priority yet.
I figured my main thrust of effort should be to push the cohesion agenda across the two qpid
brokers and beyond. I think that this was actually a pretty good call given some of the conversations
I've recently had with some of the other guys on AMQP management. Some of the recent work
has I think given some new impetus towards getting a joined up view on management.

> I found this (https://cwiki.apache.org/qpid/qmfv2-project-page.html).  I
> probably didn't go here the first time around because the link to it on
> https://cwiki.apache.org/qpid/qpid-management-framework.html says that it
> is "for information about the future of QMF", so I figured that it didn't
> apply yet.
That's the stuff I was referring to.

"didn't apply yet" is slightly ironic :-/, so the QMF2 protocol stuff definitely applies and
is worth a read, the API is slightly a sore point. I believe that there is a python implementation
in the "extras" directory that implements a reasonable subset of the API and my Java stuff
went perhaps a little OTT as I implemented the whole lot - console, agent, query subscriptions,
everything :-)

Unfortunately it hasn't really taken off, the QMF2 versions of the python tools such as qpid-config
actually use qpidlibtools which is an alternative API, I'm not sure that I totally agree with
all the decisions taken with that, it's very broker agent specific and I'm not keen on ObjectIds
being used in a non-opaque manner. that's all by the by though, the C++ QMF2 stuff is even
odder and has its own API that doesn't seem to be documented anywhere, I'm not sure where
that originated. 

Most C++ QMF2 related things I've seen seem to use the protocol directly. I'm personally not
keen on that. Although it's based on Map messages there's enough boiler plate to make an API
useful and given that AMQP supports binary and UTF8 strings and multiple different integer
and floating point widths there's a good argument for using an API to ensure that types are
interoperable. A good chunk of my Java QmfData class was about defensive coding to cope with
all sorts of ClassCastException hell, I got a real miscellany of binary and UTF8 strings from
C++ agents, so I needed to be careful. That's definitely something that needs to be considered
for the future management - we must do more to consider interoperability across languages.

The bottom line is that QMF2 is somewhat fragmented, not to mention that it has been C++ broker
specific (though I'm working to remedy that bit). It's something of a shame because despite
its failings I've found QMF2 to be pretty useful and works pretty well, but the reality is
that for AMQP 1.0 management something will need to be put in place that has wide vendor buy
in and that most likely won't be QMF2 as it currently stands, though I'm certainly keen to
make sure that any transition is as painless as possible. At the moment QMF is the only way
to manage the C++ broker and there are a fair number of tools out there using it, so I think
that any migration is going to have to be a bit evolutionary. It's a shame that the API hasn't
really taken off as that might have helped isolate clients from changes to the underlying
management protocol. As it is the QMF2 protocol is exposed by several fragmented, APIs which
is clearly the exact opposite of what might be considered useful abstraction :-(

Do keep following this list though, I think that we really need to learn from some of the
lessons of QMF and I think that one of those lessons is better communication and more open


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message