> 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
