WebRTC for M2M? Think backwards.[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]
If you think about it, M2M has two things it handles:
- Devices. Of various shapes and sizes
- Networking. Between those devices, with the help of a backend
What should be WebRTC’s role in the Internet of Things? Does it have a place there? Does it make any sense, or is this gut feeling of mine just me hyping myself around with this new toy?
I can’t really be sure of the answer, but I think most of us have been looking at WebRTC in the wrong way. It is why I took the time to discuss the data channel uses and why I am stabbing at M2M this time.
Here’s what I think:
Most of us look at WebRTC and what we see is a flashy video (not Flash – just flashy). It has all that complex bells and whistles, and it is so easy to use compared to what we had before that we go and tinker with it, taking the time to build a video calling app and hosting it somewhere. When we get down into the details, we then see that it can do voice only as well and that there’s a data channel somewhere in there. This is VoIP thinking.
If we look at WebRTC from an M2M prism, then first and foremost it provides a data channel, and only later voice and video. And that data channel is hard to crack, because it doesn’t stand on its own and it requires a web browser.
Back to M2M.
We have devices. We have a network. We have servers. We have a use case to develop.
Backend is easy. We use web tools to build it. Probably a bit of analytics and Big Data would make sense as well, but this is all known territory.
Network is ok. We’ve done that as well. And we know how to do this at web scale if needed.
Devices. We can do devices, but somehow using the traditional ways doesn’t look that attractive anymore. You know – taking a proprietary real-time operating system that nobody uses, developing the device drivers on our own, writing code in C (or directly to the DSP god forbid) and then dealing with the lack of good IDE and debug tools. It just feels so… 80′. We might as well just go use punch cards for that part of our project.
But there’s a better way. And it fits with Atwood’s Law from 2007:
Why not use Java Script on embedded devices? With or without a visual web browser?
Here’s my suggestion (and I heard it elsewhere as well):
- Have networking done there using the same browser paradigms available today: XHR, SSE and WebSockets
- Add WebRTC to it. At the very least have the data channel implemented
- Add bindings and code to deal with voice and video on the device via WebRTC only if needed
What will happen?
It will make development a lot easier.
It will create a thriving developer ecosystem where tools will start to appear for the Internet of Things from non-commercial vendors.
Now we only need someone to bring this vision to life.