> 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 discussion.

Frase


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

Reply via email to