I can't really answer your other questions, but I can give you some feedback on one of them.
It is unlikely you will want to make this device a DCE device unless you intend to write the code to make it so. A DCE device is a combination of a device template and the DCE driver code itself. Essentially, you are writing a piece of C++ code that will connect to the DCERouter via TCP/IP and be able to send and receive DCE messages to the rest of the LinuxMCE system. This device is usually responsible for converting LinuxMCE's DCE messages into actions for a particular physical device or other piece of non-LinuxMCE software. An intermediary if you will.
For instance, if you had an amplifier connected to your core via RS232, you might want to write a device that receives DCE Volume messages (Up Down, Mute, for a simple example) from LinuxMCE and converts them into data sent to the serial port to control the actual device. Similarly if the user hits Mute on the amp, you would want the device you write to send that info back to LinuxMCE so that it knows the volume is muted. In practice, such simple applications are usually not necessary as you can use the GSD (Generic Serial Device) - this is a "framework" type device that already has the complex bits of connecting to the DCE network implemented, and sends/receives DCE messages for you, then based on which message will trigger a snippet of Ruby code to do the task needed. That way you don't need to have a dev environment or write any C++, you can just insert the right Ruby snippets into the web admin.
An example of a DCE device controlling software would be the Squeezebox system. Someone wrote a DCE device that connects to the DCE system via TCP/IP and also to the SqueezeCenter software via TCP/IP (SqueezeCenter offers a TCP/IP control interface as well as the normal web interface for exactly this purpose). It then passes commands back and forward between the two.
One of the purposes of DCE is this abstraction, so that LinuxMCE can send generic commands like volume up/down, play media, etc to non-LinuxMCE systems without having to know how those commands are actually implemented. The responsible DCE device has all that information.
In your case, the hardware in question is low level and probably doesn't need to interact directly with LinuxMCE through DCE. There are many device types that do not implement DCE because they are merely children devices types of other device types that do the interaction. Imagine them like "placeholder" containers of configuration data, rather than actual do-ers!
So why do you create a device template for your card if not to communicate through DCE? Well in this case I see 2 reasons. First it allows you to configure LinuxMCE's pnp system, so that when it sees the device you can "do stuff" to ensure that the card is configured correctly for us. eg install any drivers, setup configuration options in the driver's .conf files etc. This will allow your card to be autoconfigured for LinuxMCE as it is detected.
Second, to store critical configuration data (Device Data) that the rest of the LinuxMCE can use to communicate with the card. Specifically, I am thinking Motion as an example.
As I understand it, the Motion_Wrapper is the main security DCE device for capture cards. I've never done this, but I assume that you configure your device template to be a child device of the Motion device. Motion does all the DCE communication with LinuxMCE, and I assume it just looks for its children to find the actual video, by interrogating their Device Data. Not sure if it looks for a URL or a /dev device file in the Device Data, but probably one or the other, then uses that to do the actual reading of video.
In summary, you could write a whole DCE device just to control this card, but that is a big job and reinventing the wheel. I believe you can create a non-DCE device, that is configured to be a child of a real DCE device like Motion, so that once detected LinuxMCE knows where to add the device in the system. Then configure the pnp section of your new device so that any setup/configuration that the card needs, is done. Finally, add any Device Data necessary so that the parent DCE device can access your card.
The "principles" stuff above is broadly correct, as I understand it. But most of the video/security/motion stuff is assumption - someone will correct as necessary I'm sure. Your best bet is to look carefully at other similar devices... Establish what they are configured to be children of, to verify my assumption. Investigate what types of tasks their pnp configuration does (usually a script is run). And determine what Device Data they set, so that Motion can access them.
hth
ps. remember that LinuxMCE's pnp system is quite separate from the underlying Linux pnp. The kernel's pnp system will do the actual hardware detection, and for instance, based on the PCI ID (vendor/product) may well install the necessary kernel device driver necessary for the hardware. The hardware is now installed and working, but LinuxMCE knows nothing about it. LinuxMCE's pnp system hooks into the kernel pnp system by receiving events through the HAL. So once the kernel has done its bit, the LinuxMCE pnp system is triggered and passed pieces of information like the PCI vendor/product number, and goes about triggering the necessary Device Template based on that number to install itself (if it isn't already), so there are 2 pnps, you mostly need to worry about the LinuxMCE one, as long as the kernel successfully does its bit.
