Overview of the software modules - Revision history

Marie.o at 20:25, 17 May 2010

2010-05-17T20:25:27Z

←Older revision		Revision as of 20:25, 17 May 2010
Line 1:		Line 1:
	[[Category: Programmer's Guide]]		[[Category: Programmer's Guide]]

	~~<p>~~[[~~LinuxMCE~~ Libraries ~~DCE~~]] section explains this process in detail.~~</p>~~		[[DCE Libraries]] section explains this process in detail.
	~~<p>~~[[DCE Router]]. When a DCE Device connects, DCERouter gives it its configuration data and is responsible for receiving and forwarding any messages to and from the devices that connect to it. The most common types of messages are commands and events. All communication goes through DCE Router. If a doorbell device fires an event that the button was pushed, that event goes to DCERouter, which will forward it whatever plug-in has indicated it wants to handle that type of event. If the plug-in then wants to send a command to the media player, this command goes first to the DCE Router, which will then forward it to the media player. The DCE Devices never communicate with each other directly--everything goes through DCE Router. Devices can create their own types of messages specific to them--not just commands and events. For example, a DVD player may send a message that contains a screen capture, or a TV program may send a stream of messages with streaming video. To DCE Router it makes no difference. Messages just have sources and destinations, and DCE Router does not care what type of message it is.~~</p>~~
	~~<p>~~DCERouter also allows you to [[Message Interceptors]]. This means a device or plugin can say that it wants to pre-process all messages that meet a certain criteria. For example, a security plug-in may want to see all events relating to security.~~</p>~~		[[DCE Router]]. When a DCE Device connects, DCERouter gives it its configuration data and is responsible for receiving and forwarding any messages to and from the devices that connect to it. The most common types of messages are commands and events. All communication goes through DCE Router. If a doorbell device fires an event that the button was pushed, that event goes to DCERouter, which will forward it whatever plug-in has indicated it wants to handle that type of event. If the plug-in then wants to send a command to the media player, this command goes first to the DCE Router, which will then forward it to the media player. The DCE Devices never communicate with each other directly--everything goes through DCE Router. Devices can create their own types of messages specific to them--not just commands and events. For example, a DVD player may send a message that contains a screen capture, or a TV program may send a stream of messages with streaming video. To DCE Router it makes no difference. Messages just have sources and destinations, and DCE Router does not care what type of message it is.
	~~<p>~~Plug-ins are DCE Devices that run within the DCERouter's memory space. They are DCE Devices just like any other, and they are created like any other DCE Device. The code is the same, it's just a compilation option whether the device is built as a normal DCE Device, which runs in its own memory space and communicates with DCERouter over a socket, or if it's a plug-in which gets loaded into DCERouter's memory space. Plug-ins have the ability to get pointers to the in-memory instance of the other plug-ins so they can share memory and call each others methods.~~</p>~~
	~~<p>~~The [[Orbiter]] library. When the user presses a button on the phone, Bluetooth Dongle forwards this to the embedded Orbiter which treats it just like any other input.~~</p>~~		DCERouter also allows you to [[Message Interceptors]]. This means a device or plugin can say that it wants to pre-process all messages that meet a certain criteria. For example, a security plug-in may want to see all events relating to security.
	~~<p>~~The user interface for both the stand-alone Orbiters and the embedded Orbiters for mobile phones is stored in the same [[~~LinuxMCE_main~~ database]] does the pre-rendering. It determines what the user interface needs to include based on settings in the database, such as the type of Orbiter, the skin, language options, and so on. It then pre-renders embedded graphics and text, and creates a simple input file for the Orbiter which contains that Orbiter's particular UI.~~</p>~~
	~~<p>~~Because LinuxMCE is so database intensive and absolutely everything is stored in the LinuxMCE-main database, we needed a tool to handle synchronizing database changes. [[sqlCVS]] is for a SQL database what CVS is for source code. It's actually a general-purpose tool and can be used for any database. Nothing in it is specific to LinuxMCE. It allows a user to checkout a local working copy of the database and make their local changes. The user can then check-in those changes, or update his local copy with the changes from others. Like CVS it supports forking and merging, and you can extract snapshots of the database at any given time. It also tracks which users own which records and prevents unauthorized changes to the database. Commits are atomic, so you can undo a check-in that a user made at any time.~~</p>~~		Plug-ins are DCE Devices that run within the DCERouter's memory space. They are DCE Devices just like any other, and they are created like any other DCE Device. The code is the same, it's just a compilation option whether the device is built as a normal DCE Device, which runs in its own memory space and communicates with DCERouter over a socket, or if it's a plug-in which gets loaded into DCERouter's memory space. Plug-ins have the ability to get pointers to the in-memory instance of the other plug-ins so they can share memory and call each others methods.
	~~<p>~~LinuxMCE also needed a general purpose class generator that makes it very easy to work with a relational database in an object-oriented manner. [[sql2cpp]] analyzes a database, determines foreign keys and relationships, and builds a complete class structure to represent the database. The programmer can traverse relationships across multiple tables with 1 line of code. It completely eliminates the need to write SQL statements. And if the database schema changes, it will change the class structure so any code that relies on outdated schema will no longer compile, making it much easier to keep the code current. This is also a general-purpose tool that is not specific to LinuxMCE.~~</p>~~
	~~<p>~~The "Kick-Start" project is a collection of scripts and utilities to install LinuxMCE on a variety of operating systems and platforms. It contains information about what software depends on other software, and where to locate each piece of software on each platform. Since the database information is general purpose, it can be reused by other unrelated projects as well.~~</p>~~		The [[Orbiter]] library. When the user presses a button on the phone, Bluetooth Dongle forwards this to the embedded Orbiter which treats it just like any other input.
	~~<p>~~There are also a collection of [[LinuxMCE Scripts]].~~</p>~~
	~~<p>LinuxMCE~~ specifically decided to sacrifice revenues from software sales, focusing its sales efforts exclusively on embedded solutions, so that it could work more closely with the open source community and develop a general-purpose platform that makes it very easy for programmers to build upon. LinuxMCE is happy to assist any programmers to want to build DCE wrappers for their existing projects, or make new additions to LinuxMCE. You can email the administrator responsible for the project you are interested in, or click "Live Support" to get instant help at any time.~~</p>~~		The user interface for both the stand-alone Orbiters and the embedded Orbiters for mobile phones is stored in the same [[pluto_main database]] does the pre-rendering. It determines what the user interface needs to include based on settings in the database, such as the type of Orbiter, the skin, language options, and so on. It then pre-renders embedded graphics and text, and creates a simple input file for the Orbiter which contains that Orbiter's particular UI.

			Because LinuxMCE is so database intensive and absolutely everything is stored in the LinuxMCE-main database, we needed a tool to handle synchronizing database changes. [[sqlCVS]] is for a SQL database what CVS is for source code. It's actually a general-purpose tool and can be used for any database. Nothing in it is specific to LinuxMCE. It allows a user to checkout a local working copy of the database and make their local changes. The user can then check-in those changes, or update his local copy with the changes from others. Like CVS it supports forking and merging, and you can extract snapshots of the database at any given time. It also tracks which users own which records and prevents unauthorized changes to the database. Commits are atomic, so you can undo a check-in that a user made at any time.

			LinuxMCE also needed a general purpose class generator that makes it very easy to work with a relational database in an object-oriented manner. [[sql2cpp]] analyzes a database, determines foreign keys and relationships, and builds a complete class structure to represent the database. The programmer can traverse relationships across multiple tables with 1 line of code. It completely eliminates the need to write SQL statements. And if the database schema changes, it will change the class structure so any code that relies on outdated schema will no longer compile, making it much easier to keep the code current. This is also a general-purpose tool that is not specific to LinuxMCE.

			The "Kick-Start" project is a collection of scripts and utilities to install LinuxMCE on a variety of operating systems and platforms. It contains information about what software depends on other software, and where to locate each piece of software on each platform. Since the database information is general purpose, it can be reused by other unrelated projects as well.

			There are also a collection of [[LinuxMCE Scripts]].

			PlutoHome specifically decided to sacrifice revenues from software sales, focusing its sales efforts exclusively on embedded solutions, so that it could work more closely with the open source community and develop a general-purpose platform that makes it very easy for programmers to build upon. LinuxMCE is happy to assist any programmers to want to build DCE wrappers for their existing projects, or make new additions to LinuxMCE. You can email the administrator responsible for the project you are interested in, or click "Live Support" to get instant help at any time.

	<p>index.php?section=modules&package=0 for a complete list of all the software that makes up LinuxMCE.</p>		<p>index.php?section=modules&package=0 for a complete list of all the software that makes up LinuxMCE.</p>

Jerry finn at 09:21, 19 March 2007

2007-03-19T09:21:37Z

Juliet at 12:43, 15 March 2007

2007-03-15T12:43:07Z

←Older revision		Revision as of 12:43, 15 March 2007
Line 6:		Line 6:
	<p>Plug-ins are DCE Devices that run within the DCERouter's memory space. They are DCE Devices just like any other, and they are created like any other DCE Device. The code is the same, it's just a compilation option whether the device is built as a normal DCE Device, which runs in its own memory space and communicates with DCERouter over a socket, or if it's a plug-in which gets loaded into DCERouter's memory space. Plug-ins have the ability to get pointers to the in-memory instance of the other plug-ins so they can share memory and call each others methods.</p>		<p>Plug-ins are DCE Devices that run within the DCERouter's memory space. They are DCE Devices just like any other, and they are created like any other DCE Device. The code is the same, it's just a compilation option whether the device is built as a normal DCE Device, which runs in its own memory space and communicates with DCERouter over a socket, or if it's a plug-in which gets loaded into DCERouter's memory space. Plug-ins have the ability to get pointers to the in-memory instance of the other plug-ins so they can share memory and call each others methods.</p>
	<p>The [[Orbiter]] library. When the user presses a button on the phone, Bluetooth Dongle forwards this to the embedded Orbiter which treats it just like any other input.</p>		<p>The [[Orbiter]] library. When the user presses a button on the phone, Bluetooth Dongle forwards this to the embedded Orbiter which treats it just like any other input.</p>
	<p>The user interface for both the stand-alone Orbiters and the embedded Orbiters for mobile phones is stored in the same [[pluto_main database]] does the pre-rendering. It determines what the user interface needs to include based on settings in the database, such as ~~teh~~ type of Orbiter, the skin, language options, and so on. It then pre-renders embedded graphics and text, and creates a simple input file for the Orbiter which contains that Orbiter's particular UI.</p>		<p>The user interface for both the stand-alone Orbiters and the embedded Orbiters for mobile phones is stored in the same [[pluto_main database]] does the pre-rendering. It determines what the user interface needs to include based on settings in the database, such as the type of Orbiter, the skin, language options, and so on. It then pre-renders embedded graphics and text, and creates a simple input file for the Orbiter which contains that Orbiter's particular UI.</p>
	<p>Because ~~Pluto~~ is so database intensive and absolutely everything is stored in the pluto-main database, we needed a tool to handle synchronizing database changes. [[sqlCVS]] is for a SQL database what CVS is for source code. It's actually a general-purpose tool and can be used for any database. Nothing in it is specific to ~~Pluto~~. It allows a user to checkout a local working copy of the database and make their local changes. The user can then ~~checkin~~ those changes, or update his local copy with the changes from others. Like CVS it supports forking and merging, and you can extract snapshots of the database at any given time. It also tracks which users own which records and prevents unauthorized changes to the ~~databse~~. Commits are atomic, so you can undo a check-in that a user made at any time.</p>		<p>Because LinuxMCE is so database intensive and absolutely everything is stored in the pluto-main database, we needed a tool to handle synchronizing database changes. [[sqlCVS]] is for a SQL database what CVS is for source code. It's actually a general-purpose tool and can be used for any database. Nothing in it is specific to LinuxMCE. It allows a user to checkout a local working copy of the database and make their local changes. The user can then check-in those changes, or update his local copy with the changes from others. Like CVS it supports forking and merging, and you can extract snapshots of the database at any given time. It also tracks which users own which records and prevents unauthorized changes to the database. Commits are atomic, so you can undo a check-in that a user made at any time.</p>
	<p>~~Pluto~~ also needed a general purpose class generator that makes it very easy to work with a relational database in an object-oriented manner. [[sql2cpp]] analyzes a database, determines foreign keys and relationships, and builds a complete class structure to represent the database. The programmer can traverse relationships across multiple tables with 1 line of code. It completely eliminates the need to write SQL statements. And if the database schema changes, it will change the class structure so any code that relies on outdated schema will no longer compile, making it much easier to keep the code current. This is also a general-purpose tool that is not specific to ~~Pluto~~.</p>		<p>LinuxMCE also needed a general purpose class generator that makes it very easy to work with a relational database in an object-oriented manner. [[sql2cpp]] analyzes a database, determines foreign keys and relationships, and builds a complete class structure to represent the database. The programmer can traverse relationships across multiple tables with 1 line of code. It completely eliminates the need to write SQL statements. And if the database schema changes, it will change the class structure so any code that relies on outdated schema will no longer compile, making it much easier to keep the code current. This is also a general-purpose tool that is not specific to LinuxMCE.</p>
	<p>The "Kick-Start" project is a collection of scripts and ~~utilties~~ to install ~~Pluto~~ on a variety of operating systems and platforms. It contains information about what software depends on other software, and where to locate each piece of software on each platform. Since the database information is general purpose, it can be reused by other unrelated projects as well.</p>		<p>The "Kick-Start" project is a collection of scripts and utilities to install LinuxMCE on a variety of operating systems and platforms. It contains information about what software depends on other software, and where to locate each piece of software on each platform. Since the database information is general purpose, it can be reused by other unrelated projects as well.</p>
	<p>There are also a collection of [[Pluto Scripts]].</p>		<p>There are also a collection of [[Pluto Scripts]].</p>
	<p>~~Pluto~~ specifically decided to sacrifice revenues from software sales, focusing its sales efforts exclusively on embedded solutions, so that it could work more closely with the open source community and develop a general-purpose platform that makes it very easy for programmers to build upon. ~~Pluto~~ is happy to assist any programmers to want to build DCE wrappers for their existing projects, or make new additions to ~~Pluto~~. You can email the administrator responsible for the project you are interested in, or click "Live Support" to get instant help at any time.</p>		<p>LinuxMCE specifically decided to sacrifice revenues from software sales, focusing its sales efforts exclusively on embedded solutions, so that it could work more closely with the open source community and develop a general-purpose platform that makes it very easy for programmers to build upon. LinuxMCE is happy to assist any programmers to want to build DCE wrappers for their existing projects, or make new additions to LinuxMCE. You can email the administrator responsible for the project you are interested in, or click "Live Support" to get instant help at any time.</p>
	<p>index.php?section=modules&package=0 for a complete list of all the software that makes up ~~Pluto~~.</p>		<p>index.php?section=modules&package=0 for a complete list of all the software that makes up LinuxMCE.</p>

Wikiadmin at 03:00, 29 August 2006

2006-08-29T03:00:49Z

←Older revision		Revision as of 03:00, 29 August 2006
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>[[Pluto Libraries DCE]] section explains this process in detail.</p>		<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>[[Category: Programmer's Guide]]

			<p>[[Pluto Libraries DCE]] section explains this process in detail.</p>
	<p>[[DCE Router]]. When a DCE Device connects, DCERouter gives it its configuration data and is responsible for receiving and forwarding any messages to and from the devices that connect to it. The most common types of messages are commands and events. All communication goes through DCE Router. If a doorbell device fires an event that the button was pushed, that event goes to DCERouter, which will forward it whatever plug-in has indicated it wants to handle that type of event. If the plug-in then wants to send a command to the media player, this command goes first to the DCE Router, which will then forward it to the media player. The DCE Devices never communicate with each other directly--everything goes through DCE Router. Devices can create their own types of messages specific to them--not just commands and events. For example, a DVD player may send a message that contains a screen capture, or a TV program may send a stream of messages with streaming video. To DCE Router it makes no difference. Messages just have sources and destinations, and DCE Router does not care what type of message it is.</p>		<p>[[DCE Router]]. When a DCE Device connects, DCERouter gives it its configuration data and is responsible for receiving and forwarding any messages to and from the devices that connect to it. The most common types of messages are commands and events. All communication goes through DCE Router. If a doorbell device fires an event that the button was pushed, that event goes to DCERouter, which will forward it whatever plug-in has indicated it wants to handle that type of event. If the plug-in then wants to send a command to the media player, this command goes first to the DCE Router, which will then forward it to the media player. The DCE Devices never communicate with each other directly--everything goes through DCE Router. Devices can create their own types of messages specific to them--not just commands and events. For example, a DVD player may send a message that contains a screen capture, or a TV program may send a stream of messages with streaming video. To DCE Router it makes no difference. Messages just have sources and destinations, and DCE Router does not care what type of message it is.</p>
	<p>DCERouter also allows you to [[Message Interceptors]]. This means a device or plugin can say that it wants to pre-process all messages that meet a certain criteria. For example, a security plug-in may want to see all events relating to security.</p>		<p>DCERouter also allows you to [[Message Interceptors]]. This means a device or plugin can say that it wants to pre-process all messages that meet a certain criteria. For example, a security plug-in may want to see all events relating to security.</p>
Line 11:		Line 13:
	<p>Pluto specifically decided to sacrifice revenues from software sales, focusing its sales efforts exclusively on embedded solutions, so that it could work more closely with the open source community and develop a general-purpose platform that makes it very easy for programmers to build upon. Pluto is happy to assist any programmers to want to build DCE wrappers for their existing projects, or make new additions to Pluto. You can email the administrator responsible for the project you are interested in, or click "Live Support" to get instant help at any time.</p>		<p>Pluto specifically decided to sacrifice revenues from software sales, focusing its sales efforts exclusively on embedded solutions, so that it could work more closely with the open source community and develop a general-purpose platform that makes it very easy for programmers to build upon. Pluto is happy to assist any programmers to want to build DCE wrappers for their existing projects, or make new additions to Pluto. You can email the administrator responsible for the project you are interested in, or click "Live Support" to get instant help at any time.</p>
	<p>index.php?section=modules&package=0 for a complete list of all the software that makes up Pluto.</p>		<p>index.php?section=modules&package=0 for a complete list of all the software that makes up Pluto.</p>

Wikiadmin: Imported document

2006-06-05T16:46:42Z

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>[[Pluto Libraries DCE]] section explains this process in detail.
[[DCE Router]]. When a DCE Device connects, DCERouter gives it its configuration data and is responsible for receiving and forwarding any messages to and from the devices that connect to it. The most common types of messages are commands and events. All communication goes through DCE Router. If a doorbell device fires an event that the button was pushed, that event goes to DCERouter, which will forward it whatever plug-in has indicated it wants to handle that type of event. If the plug-in then wants to send a command to the media player, this command goes first to the DCE Router, which will then forward it to the media player. The DCE Devices never communicate with each other directly--everything goes through DCE Router. Devices can create their own types of messages specific to them--not just commands and events. For example, a DVD player may send a message that contains a screen capture, or a TV program may send a stream of messages with streaming video. To DCE Router it makes no difference. Messages just have sources and destinations, and DCE Router does not care what type of message it is.
DCERouter also allows you to [[Message Interceptors]]. This means a device or plugin can say that it wants to pre-process all messages that meet a certain criteria. For example, a security plug-in may want to see all events relating to security.
Plug-ins are DCE Devices that run within the DCERouter's memory space. They are DCE Devices just like any other, and they are created like any other DCE Device. The code is the same, it's just a compilation option whether the device is built as a normal DCE Device, which runs in its own memory space and communicates with DCERouter over a socket, or if it's a plug-in which gets loaded into DCERouter's memory space. Plug-ins have the ability to get pointers to the in-memory instance of the other plug-ins so they can share memory and call each others methods.
The [[Orbiter]] library. When the user presses a button on the phone, Bluetooth Dongle forwards this to the embedded Orbiter which treats it just like any other input.
The user interface for both the stand-alone Orbiters and the embedded Orbiters for mobile phones is stored in the same [[pluto_main database]] does the pre-rendering. It determines what the user interface needs to include based on settings in the database, such as teh type of Orbiter, the skin, language options, and so on. It then pre-renders embedded graphics and text, and creates a simple input file for the Orbiter which contains that Orbiter's particular UI.
Because Pluto is so database intensive and absolutely everything is stored in the pluto-main database, we needed a tool to handle synchronizing database changes. [[sqlCVS]] is for a SQL database what CVS is for source code. It's actually a general-purpose tool and can be used for any database. Nothing in it is specific to Pluto. It allows a user to checkout a local working copy of the database and make their local changes. The user can then checkin those changes, or update his local copy with the changes from others. Like CVS it supports forking and merging, and you can extract snapshots of the database at any given time. It also tracks which users own which records and prevents unauthorized changes to the databse. Commits are atomic, so you can undo a check-in that a user made at any time.
Pluto also needed a general purpose class generator that makes it very easy to work with a relational database in an object-oriented manner. [[sql2cpp]] analyzes a database, determines foreign keys and relationships, and builds a complete class structure to represent the database. The programmer can traverse relationships across multiple tables with 1 line of code. It completely eliminates the need to write SQL statements. And if the database schema changes, it will change the class structure so any code that relies on outdated schema will no longer compile, making it much easier to keep the code current. This is also a general-purpose tool that is not specific to Pluto.
The "Kick-Start" project is a collection of scripts and utilties to install Pluto on a variety of operating systems and platforms. It contains information about what software depends on other software, and where to locate each piece of software on each platform. Since the database information is general purpose, it can be reused by other unrelated projects as well.
There are also a collection of [[Pluto Scripts]].
Pluto specifically decided to sacrifice revenues from software sales, focusing its sales efforts exclusively on embedded solutions, so that it could work more closely with the open source community and develop a general-purpose platform that makes it very easy for programmers to build upon. Pluto is happy to assist any programmers to want to build DCE wrappers for their existing projects, or make new additions to Pluto. You can email the administrator responsible for the project you are interested in, or click "Live Support" to get instant help at any time.
index.php?section=modules&package=0 for a complete list of all the software that makes up Pluto.

←Older revision		Revision as of 09:21, 19 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>[[Category: Programmer's Guide]]		[[Category: Programmer's Guide]]

	<p>[[~~Pluto~~ Libraries DCE]] section explains this process in detail.</p>		<p>[[LinuxMCE Libraries DCE]] section explains this process in detail.</p>
	<p>[[DCE Router]]. When a DCE Device connects, DCERouter gives it its configuration data and is responsible for receiving and forwarding any messages to and from the devices that connect to it. The most common types of messages are commands and events. All communication goes through DCE Router. If a doorbell device fires an event that the button was pushed, that event goes to DCERouter, which will forward it whatever plug-in has indicated it wants to handle that type of event. If the plug-in then wants to send a command to the media player, this command goes first to the DCE Router, which will then forward it to the media player. The DCE Devices never communicate with each other directly--everything goes through DCE Router. Devices can create their own types of messages specific to them--not just commands and events. For example, a DVD player may send a message that contains a screen capture, or a TV program may send a stream of messages with streaming video. To DCE Router it makes no difference. Messages just have sources and destinations, and DCE Router does not care what type of message it is.</p>		<p>[[DCE Router]]. When a DCE Device connects, DCERouter gives it its configuration data and is responsible for receiving and forwarding any messages to and from the devices that connect to it. The most common types of messages are commands and events. All communication goes through DCE Router. If a doorbell device fires an event that the button was pushed, that event goes to DCERouter, which will forward it whatever plug-in has indicated it wants to handle that type of event. If the plug-in then wants to send a command to the media player, this command goes first to the DCE Router, which will then forward it to the media player. The DCE Devices never communicate with each other directly--everything goes through DCE Router. Devices can create their own types of messages specific to them--not just commands and events. For example, a DVD player may send a message that contains a screen capture, or a TV program may send a stream of messages with streaming video. To DCE Router it makes no difference. Messages just have sources and destinations, and DCE Router does not care what type of message it is.</p>
	<p>DCERouter also allows you to [[Message Interceptors]]. This means a device or plugin can say that it wants to pre-process all messages that meet a certain criteria. For example, a security plug-in may want to see all events relating to security.</p>		<p>DCERouter also allows you to [[Message Interceptors]]. This means a device or plugin can say that it wants to pre-process all messages that meet a certain criteria. For example, a security plug-in may want to see all events relating to security.</p>
	<p>Plug-ins are DCE Devices that run within the DCERouter's memory space. They are DCE Devices just like any other, and they are created like any other DCE Device. The code is the same, it's just a compilation option whether the device is built as a normal DCE Device, which runs in its own memory space and communicates with DCERouter over a socket, or if it's a plug-in which gets loaded into DCERouter's memory space. Plug-ins have the ability to get pointers to the in-memory instance of the other plug-ins so they can share memory and call each others methods.</p>		<p>Plug-ins are DCE Devices that run within the DCERouter's memory space. They are DCE Devices just like any other, and they are created like any other DCE Device. The code is the same, it's just a compilation option whether the device is built as a normal DCE Device, which runs in its own memory space and communicates with DCERouter over a socket, or if it's a plug-in which gets loaded into DCERouter's memory space. Plug-ins have the ability to get pointers to the in-memory instance of the other plug-ins so they can share memory and call each others methods.</p>
	<p>The [[Orbiter]] library. When the user presses a button on the phone, Bluetooth Dongle forwards this to the embedded Orbiter which treats it just like any other input.</p>		<p>The [[Orbiter]] library. When the user presses a button on the phone, Bluetooth Dongle forwards this to the embedded Orbiter which treats it just like any other input.</p>
	<p>The user interface for both the stand-alone Orbiters and the embedded Orbiters for mobile phones is stored in the same [[~~pluto_main~~ database]] does the pre-rendering. It determines what the user interface needs to include based on settings in the database, such as the type of Orbiter, the skin, language options, and so on. It then pre-renders embedded graphics and text, and creates a simple input file for the Orbiter which contains that Orbiter's particular UI.</p>		<p>The user interface for both the stand-alone Orbiters and the embedded Orbiters for mobile phones is stored in the same [[LinuxMCE_main database]] does the pre-rendering. It determines what the user interface needs to include based on settings in the database, such as the type of Orbiter, the skin, language options, and so on. It then pre-renders embedded graphics and text, and creates a simple input file for the Orbiter which contains that Orbiter's particular UI.</p>
	<p>Because LinuxMCE is so database intensive and absolutely everything is stored in the ~~pluto~~-main database, we needed a tool to handle synchronizing database changes. [[sqlCVS]] is for a SQL database what CVS is for source code. It's actually a general-purpose tool and can be used for any database. Nothing in it is specific to LinuxMCE. It allows a user to checkout a local working copy of the database and make their local changes. The user can then check-in those changes, or update his local copy with the changes from others. Like CVS it supports forking and merging, and you can extract snapshots of the database at any given time. It also tracks which users own which records and prevents unauthorized changes to the database. Commits are atomic, so you can undo a check-in that a user made at any time.</p>		<p>Because LinuxMCE is so database intensive and absolutely everything is stored in the LinuxMCE-main database, we needed a tool to handle synchronizing database changes. [[sqlCVS]] is for a SQL database what CVS is for source code. It's actually a general-purpose tool and can be used for any database. Nothing in it is specific to LinuxMCE. It allows a user to checkout a local working copy of the database and make their local changes. The user can then check-in those changes, or update his local copy with the changes from others. Like CVS it supports forking and merging, and you can extract snapshots of the database at any given time. It also tracks which users own which records and prevents unauthorized changes to the database. Commits are atomic, so you can undo a check-in that a user made at any time.</p>
	<p>LinuxMCE also needed a general purpose class generator that makes it very easy to work with a relational database in an object-oriented manner. [[sql2cpp]] analyzes a database, determines foreign keys and relationships, and builds a complete class structure to represent the database. The programmer can traverse relationships across multiple tables with 1 line of code. It completely eliminates the need to write SQL statements. And if the database schema changes, it will change the class structure so any code that relies on outdated schema will no longer compile, making it much easier to keep the code current. This is also a general-purpose tool that is not specific to LinuxMCE.</p>		<p>LinuxMCE also needed a general purpose class generator that makes it very easy to work with a relational database in an object-oriented manner. [[sql2cpp]] analyzes a database, determines foreign keys and relationships, and builds a complete class structure to represent the database. The programmer can traverse relationships across multiple tables with 1 line of code. It completely eliminates the need to write SQL statements. And if the database schema changes, it will change the class structure so any code that relies on outdated schema will no longer compile, making it much easier to keep the code current. This is also a general-purpose tool that is not specific to LinuxMCE.</p>
	<p>The "Kick-Start" project is a collection of scripts and utilities to install LinuxMCE on a variety of operating systems and platforms. It contains information about what software depends on other software, and where to locate each piece of software on each platform. Since the database information is general purpose, it can be reused by other unrelated projects as well.</p>		<p>The "Kick-Start" project is a collection of scripts and utilities to install LinuxMCE on a variety of operating systems and platforms. It contains information about what software depends on other software, and where to locate each piece of software on each platform. Since the database information is general purpose, it can be reused by other unrelated projects as well.</p>
	<p>There are also a collection of [[~~Pluto~~ Scripts]].</p>		<p>There are also a collection of [[LinuxMCE Scripts]].</p>
	<p>LinuxMCE specifically decided to sacrifice revenues from software sales, focusing its sales efforts exclusively on embedded solutions, so that it could work more closely with the open source community and develop a general-purpose platform that makes it very easy for programmers to build upon. LinuxMCE is happy to assist any programmers to want to build DCE wrappers for their existing projects, or make new additions to LinuxMCE. You can email the administrator responsible for the project you are interested in, or click "Live Support" to get instant help at any time.</p>		<p>LinuxMCE specifically decided to sacrifice revenues from software sales, focusing its sales efforts exclusively on embedded solutions, so that it could work more closely with the open source community and develop a general-purpose platform that makes it very easy for programmers to build upon. LinuxMCE is happy to assist any programmers to want to build DCE wrappers for their existing projects, or make new additions to LinuxMCE. You can email the administrator responsible for the project you are interested in, or click "Live Support" to get instant help at any time.</p>
	<p>index.php?section=modules&package=0 for a complete list of all the software that makes up LinuxMCE.</p>		<p>index.php?section=modules&package=0 for a complete list of all the software that makes up LinuxMCE.</p>