DCERouter Programmer's Guide - Revision history

Marie.o: DCE Router Programmer's Guide moved to DCERouter Programmer's Guide

2012-01-04T16:48:19Z

DCE Router Programmer's Guide moved to DCERouter Programmer's Guide

←Older revision	Revision as of 16:48, 4 January 2012
(No difference)

AVJohn at 10:08, 12 April 2008

2008-04-12T10:08:29Z

←Older revision		Revision as of 10:08, 12 April 2008
Line 1:		Line 1:
	[[Category: Programmer's Guide]]		[[Category: Programmer's Guide]]

			'''[[Developers Guide]] is the most recent information regarding architecure and getting started with development.'''

	<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>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 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>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>

Marie.o: modified reference to pluto_main instead of LinuxMCE main

2008-03-13T08:13:42Z

modified reference to pluto_main instead of LinuxMCE main

←Older revision		Revision as of 08:13, 13 March 2008
Line 1:		Line 1:
	[[Category: Programmer's Guide]]		[[Category: Programmer's Guide]]
	<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 [[~~LinuxMCE_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>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 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>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 [[~~LinuxMCE_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>

Hari at 13:57, 20 December 2007

2007-12-20T13:57:39Z

←Older revision		Revision as of 13:57, 20 December 2007
Line 1:		Line 1:
			[[Category: Programmer's Guide]]
	<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 [[LinuxMCE_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>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 [[LinuxMCE_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 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>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 [[LinuxMCE_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 [[LinuxMCE_main database]] or in the pluto.conf file.</p>

Jerry finn at 08:59, 19 March 2007

2007-03-19T08:59:29Z

←Older revision		Revision as of 08:59, 19 March 2007
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>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 [[LinuxMCE_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 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>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 [[LinuxMCE_main database]] or in the pluto.conf file.</p>

Juliet at 13:03, 16 March 2007

2007-03-16T13:03:23Z

←Older revision		Revision as of 13:03, 16 March 2007
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>

Wikiadmin: Imported document

2006-06-05T16:42:52Z

Imported document

New page

<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>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>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>