Difference between revisions of "Instant Messaging in LinuxMCE"
(Initial Content,) |
(→Architecture: initial content for architecture.) |
||
| Line 6: | Line 6: | ||
The Instant Messaging system follows the pattern for other house-wide devices in pluto, namely: | The Instant Messaging system follows the pattern for other house-wide devices in pluto, namely: | ||
| + | |||
| + | ===The Devices=== | ||
* Instant_Messaging_Plugin - This plugin provides the high level functions for the Orbiter UI and basic interactions for the different instant messaging transports. It runs within the router. | * Instant_Messaging_Plugin - This plugin provides the high level functions for the Orbiter UI and basic interactions for the different instant messaging transports. It runs within the router. | ||
* Instant Messaging Devices - These individual devices provide wrappers to DCE for the different instant messaging transports. Initially there will be two of them, one for in-house communications (a very thin wrapper basically echoing messages), these devices provide the actual instant messaging logic, sending events whenever things happen, that the Instant Messaging Plugin catches, and uses to update the UI. | * Instant Messaging Devices - These individual devices provide wrappers to DCE for the different instant messaging transports. Initially there will be two of them, one for in-house communications (a very thin wrapper basically echoing messages), these devices provide the actual instant messaging logic, sending events whenever things happen, that the Instant Messaging Plugin catches, and uses to update the UI. | ||
| + | |||
| + | ===Why is the functionality split like this?=== | ||
| + | |||
| + | You may have noticed this sort of split in other aspects of the system, where you have for example the Telecom_Plugin, and Asterisk, or the Media Plugin, and its associated players. The question you may be asking yourself is, ''why?'' | ||
| + | |||
| + | The Plug-ins run as part of the DCE Router, in the same memory space. This means that the data structures of the router, and any of the other plugins are accessible. This is necessary because when we register events and data grid generators, we need to be able to have direct access to data types emitted by the other plugins, such as the Orbiter Plugin (which manages pushing events to the orbiters), and the Datagrid Plugin (which manages populating data grids on the orbiters). | ||
| + | |||
| + | The Instant_Messaging_Plugin uses the above two mentioned plugins to provide the user interface to all the orbiters in the house. | ||
Revision as of 20:37, 21 September 2008
This set of pages will comprise my notes for bringing an Instant Messaging UI and associated back-end to LinuxMCE, as well as the design considerations taken.
It was started by --Tschak909 12:22, 21 September 2008 (PDT) , but may be continued by other people during the course of its development.
Architecture
The Instant Messaging system follows the pattern for other house-wide devices in pluto, namely:
The Devices
- Instant_Messaging_Plugin - This plugin provides the high level functions for the Orbiter UI and basic interactions for the different instant messaging transports. It runs within the router.
- Instant Messaging Devices - These individual devices provide wrappers to DCE for the different instant messaging transports. Initially there will be two of them, one for in-house communications (a very thin wrapper basically echoing messages), these devices provide the actual instant messaging logic, sending events whenever things happen, that the Instant Messaging Plugin catches, and uses to update the UI.
Why is the functionality split like this?
You may have noticed this sort of split in other aspects of the system, where you have for example the Telecom_Plugin, and Asterisk, or the Media Plugin, and its associated players. The question you may be asking yourself is, why?
The Plug-ins run as part of the DCE Router, in the same memory space. This means that the data structures of the router, and any of the other plugins are accessible. This is necessary because when we register events and data grid generators, we need to be able to have direct access to data types emitted by the other plugins, such as the Orbiter Plugin (which manages pushing events to the orbiters), and the Datagrid Plugin (which manages populating data grids on the orbiters).
The Instant_Messaging_Plugin uses the above two mentioned plugins to provide the user interface to all the orbiters in the house.
