Difference between revisions of "DCERouter Programmer's Guide"
(Imported document) |
|||
| Line 1: | Line 1: | ||
| − | + | <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 | + | <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 14: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.
