pvrfan said:
I think you can make an analogy to the days before the World Wide Web. We had proprietary networks (Compuserve, AOL, etc) that were easy to use but generally expensive and none would interoperate with the others. The early internet was there with email, ftp, irc, gopher, etc--and while free--was too complicated for most of the world.
Then came http. Initially, it was much less functional than the proprietary networks but it was free and pretty good. (No security initially which we're still paying for today.) Multiple browsers emerged. Multiple servers. They worked together using a common protocol. Content exploded. Soon, web browsing killed the proprietary networks.
But, there again, though I hate to keep whining, HTTP isn't why that happened. It happened because a huge amount of work was done to define higher level constructs that sit on top of HTTP, and that's what really does the work. HTTP doesn't tell your browser how to play a video, or play an audio stream, make a phone call, or provide the means by which all of that visual formatting of content is done, or how handling user interaction logic is done. Without all that other stuff, HTTP would be fairly useless.
It wouldn't fundamentally change the internet if there were multiple commonly used protocols, since the browsers (and other clients) can easily support that. And of course that is in fact the case already. Not everything happens over HTTP, and clients must handle many protocols and technologies (SIP, RTP, RTSP, HAL, SDP, SOAP, XML, HTML, Java, Javascript, Silverlight, PHP, and on and on) in order to get the internet even up to the level it is today (which is still woeful compared to a high quality, dedicated automation system's tightness and security.)
I mean, your analogy is right, in that HTTP is sort of equivalent to a common protocol. But, until all those other, higher level protocols and standards were created (which deal with specific types of functionality, in the same way that such constructs are needed in automation to deal with different types of devices and functionality), and all those many ways of providing user interaction and display capabilities, were added on top of HTTP, the web was very, very primitive.
And the same thing will apply to any HTTP equivalent in automation. It's only the simplest level of functionality, and it's not really required to make automation 'happen'. Automation is already at the point where it's easy enough to support any device that provides a published, reasonable quality protocol. The same issues that limit automation now will continue to do so even in the presence of such a common protocol. And it's being available, in the same way that HTTP was, will only allow for a very primitive sort of 'integration', nothing like what folks expect out of a real automation solution.
And, if you look at how long it took for all those other constructs to be defined and refined, and that fact that that work involved not THAT many companies who had a vested interest in having these technologies in place, and you compare that to the situation with all of the MANY companies that would have to get on board to achieve any sort of ubiquity, and the fact that for most of those companies integration into automation systems is at best a very marginal issue, that doesn't bode too well for standards nirvana any time soon. Was that a run-on sentence or what?
In terms of multiple standards, if those standards really defined all of the high level constructs required for real integration, having more than one would be bad, because supporting even one such fully fledged standard would be a lot of work. Having to support multiples of them would be far worse. It's actually better for devices to just provide low level access to their functionality (in a quality way that takes into account the needs of automation systems), and let the automation systems provide the higher level constructs once for all devices it controls. Clearly all those fairly inexpensive devices out there aren't going to implement reams of functionality to support or interact with all kinds of other devices in anything beyond the most simplistic way, and in the face of multiple standards then obviously you are right back to needing a centralized automation system that can mediate between them anyway.
What would best serve the automation system vendor's burden would be for manufacturers to just get serious about providing high quality protocols that aren't afterthoughts full of ifs, ands, buts and gotchas. It's fine if they want to use their own msg format.
OK, anyway, that's my last bummer-rama post on the subject. I've said what I need to say. I don't want it to turn into a food fight or anything.
P.S. Just for funzies, here is what HTTP got us, and even then only with the addition of the (even then) much larger HTML standard on top of it. We've come a long way, baby.
http://www.microsoft.com/en-us/discover/1994/
