Difference between revisions of "DCERouter Programmer's Guide"

From LinuxMCE
Jump to: navigation, search
(Imported document)
 
Line 1: Line 1:
<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007.  In general any information should apply to LinuxMCE.  However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table><p>DCE Router is actually a very simple program, and consists of only 1 class: DCERouter.  This class reads in the configuration for the installation from the [[pluto_main database]] to open a socket for incoming connections.  When devices connect to it, DCE Router gives them a copy of their own configuration data, as well a list of all the other devices in the installation.  Before accepting incoming connections, it first loads all the plug-in's into it's own name space.  If your device is loaded as a Plug-in, rather than the main() function being called, the Register() function will be called, and you will be passed a pointer to the DCERouter class.</p>
+
<p>DCE Router is actually a very simple program, and consists of only 1 class: DCERouter.  This class reads in the configuration for the installation from the [[pluto_main database]] to open a socket for incoming connections.  When devices connect to it, DCE Router gives them a copy of their own configuration data, as well as a list of all the other devices in the installation.  Before accepting incoming connections, it first loads all the plug-ins into it's own name space.  If your device is loaded as a Plug-in, rather than the main() function being called, the Register() function will be called, and you will be passed a pointer to the DCERouter class.</p>
<p>You use the pointer to the DCERouter class to do primarily 2 things:  First, you can [[Message Interceptors]].  This means that you want your plug-in to get any messages that meet a certain criteria before they are forwarded to the actual destination.  You also can get a list of the other loaded plug-ins, and pointers to their primary class, derived from Command_Impl (for command implementation).  In this way plug-ins can call each other's member functions directly and implement their own plug-in architecture.  For example, the **Datagrid plug-in** receives any messages related to generating datagrids.  Orbiters generate datagrid requests when they want to display datagrids with dynamic information, such as a list of devices, or what TV shows are playing.  The Datagrid Plug-in exposes its own plug-in architecture allowing other plug-ins to **register with it** to handle certain types of datagrids.  The Datagrid plug-in is, therefore, a general purpose "router" like DCERouter is, and it hands off all datagrid processing to another plug-in that actually generates the datagrids.  This way the building of the datagrids is logically handled in the appropriate plug-in.  The Plug-in that is responsible for TV viewing will be the one that registers with the Datagrid Plug-in to build tv-related data grids.  The Media Plug-in also implements its own plug-in architecture for media devices.</p>
+
<p>You use the pointer to the DCERouter class to do primarily 2 things:  First, you can [[Message Interceptors]].  This means that you want your plug-in to get any messages that meet a certain criteria before they are forwarded to the actual destination.  You also can get a list of the other loaded plug-ins, and pointers to their primary class, derived from Command_Impl (for command implementation).  In this way plug-ins can call each other's member functions directly and implement their own plug-in architecture.  For example, the **Datagrid plug-in** receives any messages related to generating data-grids.  Orbiters generate data-grid requests when they want to display data-grids with dynamic information, such as a list of devices, or what TV shows are playing.  The Datagrid Plug-in exposes its own plug-in architecture allowing other plug-ins to **register with it** to handle certain types of data-grids.  The Datagrid plug-in is, therefore, a general purpose "router" like DCERouter is, and it hands off all data-grid processing to another plug-in that actually generates the data-grids.  This way the building of the data-grids is logically handled in the appropriate plug-in.  The Plug-in that is responsible for TV viewing will be the one that registers with the Datagrid Plug-in to build tv-related data grids.  The Media Plug-in also implements its own plug-in architecture for media devices.</p>
 
<p>To run DCERouter, you only need to be sure it has the database connection parameters so it has access to the [[pluto_main database]] or in the **pluto.conf** file.</p>
 
<p>To run DCERouter, you only need to be sure it has the database connection parameters so it has access to the [[pluto_main database]] or in the **pluto.conf** file.</p>

Revision as of 13:03, 16 March 2007

DCE Router is actually a very simple program, and consists of only 1 class: DCERouter. This class reads in the configuration for the installation from the pluto_main database to open a socket for incoming connections. When devices connect to it, DCE Router gives them a copy of their own configuration data, as well as a list of all the other devices in the installation. Before accepting incoming connections, it first loads all the plug-ins into it's own name space. If your device is loaded as a Plug-in, rather than the main() function being called, the Register() function will be called, and you will be passed a pointer to the DCERouter class.

You use the pointer to the DCERouter class to do primarily 2 things: First, you can Message Interceptors. This means that you want your plug-in to get any messages that meet a certain criteria before they are forwarded to the actual destination. You also can get a list of the other loaded plug-ins, and pointers to their primary class, derived from Command_Impl (for command implementation). In this way plug-ins can call each other's member functions directly and implement their own plug-in architecture. For example, the **Datagrid plug-in** receives any messages related to generating data-grids. Orbiters generate data-grid requests when they want to display data-grids with dynamic information, such as a list of devices, or what TV shows are playing. The Datagrid Plug-in exposes its own plug-in architecture allowing other plug-ins to **register with it** to handle certain types of data-grids. The Datagrid plug-in is, therefore, a general purpose "router" like DCERouter is, and it hands off all data-grid processing to another plug-in that actually generates the data-grids. This way the building of the data-grids is logically handled in the appropriate plug-in. The Plug-in that is responsible for TV viewing will be the one that registers with the Datagrid Plug-in to build tv-related data grids. The Media Plug-in also implements its own plug-in architecture for media devices.

To run DCERouter, you only need to be sure it has the database connection parameters so it has access to the pluto_main database or in the **pluto.conf** file.