Overview of the software modules
| 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. |
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.
