Why DCE complements UPNP, XAP, XPL and other standards?
There are lots of existing standards and protocols defining how devices in a smart home should communicate. LinuxMCE is neutral in the protocol wars, and is not promoting its internal protocol, DCE, as an alternative. We will be adding support for all the popular protocols over time.
Our focus is squarely on LinuxMCE as a consumer solution, rather than DCE as a protocol. Our goal is to deliver a product that appeals to the consumer, and consumers buy solutions, not protocols. A typical consumer doesn't walk into an electronics store and asks for a network audio player that supports UPNP over TCP/IP, connects via an RJ45 connector to his LAN and can render streaming MP3 files. Rather, he just wants a way to listen to his music in the kitchen.
Of course, the protocols are necessary and can make or break the user's experience. But, at LinuxMCE, that's not our focus. We will let the experts work out the protocols-our expertise is delivering a user-friendly solution. Therefore, rather than competing with protocols, we see LinuxMCE as their greatest asset. If you want to promote your protocol or device, we will work with you to make LinuxMCE support that protocol, and then you will be able to offer consumers a turnkey solution based on your protocol.
As a protocol, LinuxMCE's DCE solution is different from the others because we wanted to encourage a collaborative environment, and make it very easy for any developer to start adding his own DCE devices without consulting us, or a central committee. Our different approach also makes it easier for DCE to work with and compliment the other protocols. Here's a rundown:
Everything is defined in a SQL database managed by sqlCVS
Like UPnP, xAP, etc., LinuxMCE's DCE is both a protocol and a data definition. Data definition meaning: this is Device X, these are the data parameters it needs, these are the commands it implements, these are the events it fires. The protocol itself is simple. We just defined a structure for messages that devices can pass between each other, usually commands and events. As open source, the protocol is easy enough to enhance and build upon.
The more challenging aspect is how to bring that same global collaboration process to the data definition. This is something we felt was lacking in all the current standards. We wanted a comfortable way for developers and hardware manufacturers to dive right in, adding and modifying device specifications instantly, working collaboratively with others around the globe. If you want to be able to enhance or change the way a "Light switch" works, you should be able to do so with consulting a committee, but also without breaking the existing Light Switches, and without altering the "Light Switch" standard unless the original "Light Switch" author approves. Basically, we wanted the data definition to be as dynamic as the software is.
If you are a programmer, you know that the tool which has allowed open source to grow so rapidly and become so popular is source control, like cvs. There is a master repository somewhere. Anybody can checkout a local copy. Play with it, enhance it, fix it. When done, he can check-in changes, pending approval from whoever is the owner of that particular module. Everybody around the globe can work together and build upon what others have done, but there is still a control mechanism (ie cvs) that keeps it organized.
So, we wrote a program called sqlCVS which does the same thing for a database that cvs does for source code. Every LinuxMCE user, techie or end-user, automatically checks out a local copy of the master database, along with a web-based front-end. LinuxMCE's installer does this. So, if you're a developer, you can browse through all the commands in DCE's database. Find one, say "GetVideoFrame", and see who wrote it, what parameters it takes, what devices use it, how it's used, read the comments, and see where any related source code is. If you have a device that handles video, then you can click a button to create a new device template, and add that command to your device too.
The "GetVideoFrame" command started out as something that Television and PVR devices implemented. The Orbiters would send the command so they could display multiple TV programs in picture-in-picture windows. But then the developer that created a video surveillance camera added the same command to his device. Now the end user can hit the "PIP" button on his TV remote, and choose a camera to put in the PIP window-without any change to the remote control software. Maybe you want to add a new parameter to the "GetVideoFrame", such as the aspect ratio. You can do that-adding parameters does not break any existing devices. But, perhaps you want to change an existing parameter. Maybe you want to add "TIFF" as an option to the "Format" parameter. You can do that on your local copy, and work on the source code to implement it. When you choose to commit your changes, sqlCVS tells you that you don't have permission to change that parameter and will give you a batch number and an ID of the person responsible for that command. You can send the responsible person a message through LinuxMCE asking him to review and approve your batch. Once he does, your changes become committed to the "Development" repository. When the developers feel they have a version ready for release, they notify the testing department, which runs a sqlCVS command to merge the changes into the "Testing" repository. When it's been thoroughly tested, they merge the changes into the "Release" repository, and the end-users systems automatically update themselves.
This allows anybody to build upon the data definition without fear of breaking anything. You can add a device, create commands, etc., knowing anybody else can build upon your work, but that you will always be notified and given the option of approving or denying changes to your device. For the end user, the entire process is completely invisible. All the end user sees is that over time more devices start doing more and more things.
We felt this was a much better solution than either (a) having a central committee that has to review and approve all changes to the specification, slowing down development, or (b) allowing a free-for-all where anybody can change anything and break other people's work. The goal is a dynamic and flexible platform.
This also makes DCE very compatible with other protocols and standards. For example, whoever is responsible for the specification of a UPnP thermostat can create a device "UPnP thermostat", then add the various data, commands and events that device uses. As the owner of that device, he knows that nobody else will be able to commit any changes to his specification without his approval. If the data definition for a UPnP thermostat changes, it only takes minutes to make those changes on the DCE web page. sqlCVS automatically handles versioning the database, so that it is always in sync with the source code, keeps a full history of all modifications, allows rolling back unwanted changes and checking out snapshots at various times.
Easy to create DCE devices with DCEGen
You can create a DCE device in only a couple of minutes. Just add the device using the web interface, define the data, command and events, and run DCEGen. DCEGen will build you a complete C++ program with stubs for you to implement your commands, and functions to call to fire events and get/set data parameters. It's ready to compile and run on both Windows with VS.net, and Linux with gcc. And it has lots of libraries and widget classes to automate sorts of things. For example, if you want to send the "Pause" command to all media players within a room, it's just 1 line of code. When you change the data definition, rerun DCEGen and it will merge those changes back into your source code.
Very simple plug-and-play protocol
If your device is IP based, you can specify ranges of Mac Addresses and a configure script. When the user plugs any such device into the home network, LinuxMCE's PnP back-end will see the Mac Address, automatically add the device and call the configure script.
Granted this is a very simple approach, and doesn't have the sophistication of a standard like UPnP. However, we maintain that all the end user cares about is that he plugs his network audio player into a network jack, and immediately he can hit the 'playlist' button on his remote and his favorite music starts playing. We added a device template for the Squeeze Box network audio player by Slim Devices, and took only a couple hours to write a configure script. After that, it worked. Now our users are able to plug in a Squeeze Box. Their mobile phone beeps, says "Enjoy your Squeeze Box". They can hit "Playlist", choose some music, and it starts playing.
So, while we actively support the sophisticated protocols, like UPnP, having a mechanism like this that allows anyone to add PnP support for a device without even requiring contact with the hardware manufacturer can allow a lot more devices to be supported more quickly, promoting the whole concept of PNP.
