Thanks for the links to the talks.
There are several aspects to this that I think will be a long discussion and unfortunately I don't have time to type down here in length. Nor have I clearly categorized all the various points that arise yet.
The short answer is: there's no immediate plans to do anything with mosquito on our part. Obviously this is an Open Source project so contributions are welcome there.
The longer answer revolves around several points:
1) Broker-based messaging may well make sense for a network of sensors.
2) For reliability, a broker-based architecture requires fail-over options that are non-trivial (see other message-brokers and their high availability solutions)
3) Reliability of message delivery may not be a typical requirement for sensor data however (data loss is not critical)
4) Unclear what the advantages are with a message broker on a mesh network
5) While IBM loves to push message brokers wherever they go, there's still no agreement on the physical layer protocols (zigbee, zwave, 6lowpan, dash7, you-name-it) which is a higher level issue right now (unclear roadmaps all around) – once the network level gets some clarity, it's easier to start ponder upon transport layer semantics
6) it still doesn't solve the application layer questions which are critical to provide rational user experience to the end-user – yes I can push through 60 octet message through zigbee but what are the semantics embedded into those 60 octets? Is it an integer value or a string that I should interpret as a number? Will it contain decimal number? And is the decimal separator a dot or comma? And once I figure out the 60 octet message was a decimal number of some kind, did it indicate current temperature or wind-speed?
So there's no solid base right now on any layer. It's all open from:
A) lack of consensus on network level
B) lack of consensus on transport level
C) lack of consensus on application level
And in that perspective, mosquito is yet-another-transport with yet-to-be-seen devices (sensors) that would use it.
The key to change this is to get the various hardware sensor vendors to stick to one choice over the other. The next time someone builds a water fountain actuator with arduino, will they choose mosquito or zeromq? And how do you convince others who've already made different choices to switch to mosquito.
And we've seen this same issue with xPL/xAP before.
Pushing a software out in volume is cheap and we can achieve that on the Internet (bits and bandwidth are nearly free) and with mass distribution and Open Source there's a push to a de facto solution.
The difference here is you'll need hardware to go with it. And there isn't today free or nearly free mass distribution of hardware (the 3D printers are not there yet). There's no mass distribution of Open Hardware (yet) either despite the huge inroads projects like Arduino or Raspberry Pi have made.
The mass distribution of hardware is still very much in the hands of proprietary operators. How do you get them to adopt something like mosquito?
Having said all that, I've no objections to somebody contributing work related to mosquito to OpenRemote and would love to include it. Wanted to say that again to make sure the above is not taken as a criticism of the broker itself, which looks like a good project. Also watching the talks of the people involved, they've put good thinking into the long-term vision and I agree with most of it.