Instant Messaging in LinuxMCE - Revision history

Mcefan at 02:34, 20 October 2012

2012-10-20T02:34:59Z

←Older revision		Revision as of 02:34, 20 October 2012
Line 1:		Line 1:
			[[Category:software]]
	{\| align="right"		{\| align="right"
	\| __TOC__		\| __TOC__
	\|}		\|}


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

			{{p}}

	==Goals==		==Goals==
Line 11:		Line 16:

	It was started by --[[User:Tschak909\|Tschak909]] 12:22, 21 September 2008 (PDT) , but may be continued by other people during the course of its development.		It was started by --[[User:Tschak909\|Tschak909]] 12:22, 21 September 2008 (PDT) , but may be continued by other people during the course of its development.

			{{p}}

	==Architecture==		==Architecture==

	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:
			{{p}}

	===The Devices===		===The Devices===
Line 20:		Line 28:
	* 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.
			{{p}}

	===Why is the functionality split like this?===		===Why is the functionality split like this?===
Line 30:		Line 39:

	The Instant_Messaging_Plugin uses the above two mentioned plugins to provide the user interface to all the orbiters in the house.		The Instant_Messaging_Plugin uses the above two mentioned plugins to provide the user interface to all the orbiters in the house.
			{{p}}

	====The Two Instant Messaging Devices====		====The Two Instant Messaging Devices====
Line 37:		Line 47:
	* Local House Messaging - This device, will be a thin wrapper around DCE, that allows for instant messaging to work inside the house. Its buddy list will come directly from the in-house user list, and presence will be determined by which people have been selected as users on orbiters.		* Local House Messaging - This device, will be a thin wrapper around DCE, that allows for instant messaging to work inside the house. Its buddy list will come directly from the in-house user list, and presence will be determined by which people have been selected as users on orbiters.
	* libPurple - This device, will be a DCE wrapper around the Pidgin Project's excellent libPurple multi-protocol Instant Messaging wrapper. Buddy lists will come from the accounts defined, and presence will be passed through from the respective protocols.		* libPurple - This device, will be a DCE wrapper around the Pidgin Project's excellent libPurple multi-protocol Instant Messaging wrapper. Buddy lists will come from the accounts defined, and presence will be passed through from the respective protocols.
			{{p}}

	===Example Walk-Through of Architecture===		===Example Walk-Through of Architecture===
Line 49:		Line 60:

	Once these devices are loaded, they will attempt to do their GetConfig() routines, which, after they've done any connection/housekeeping routines that they need to do, will send events for when a new person is added, and their presence information. These events will be captured by the Instant Messaging Plugin (which registered an Event Interceptor in its Register() function.) which will act upon them, and alter data structures, etc. that will be used by the respective DataGridGenerator functions. This will be used by Orbiter, any time that the data grids are on screen.		Once these devices are loaded, they will attempt to do their GetConfig() routines, which, after they've done any connection/housekeeping routines that they need to do, will send events for when a new person is added, and their presence information. These events will be captured by the Instant Messaging Plugin (which registered an Event Interceptor in its Register() function.) which will act upon them, and alter data structures, etc. that will be used by the respective DataGridGenerator functions. This will be used by Orbiter, any time that the data grids are on screen.

			{{p}}

	==Things to implement for Instant Messaging Plugin==		==Things to implement for Instant Messaging Plugin==

	The Instant Messaging plugin has commands of its own. These commands are typically sent from the Orbiters, however, they can be sent from anywhere within the system.		The Instant Messaging plugin has commands of its own. These commands are typically sent from the Orbiters, however, they can be sent from anywhere within the system.
			{{p}}

	===Instant Messaging Plugin Commands===		===Instant Messaging Plugin Commands===
Line 62:		Line 76:

	Notice that there are no log on/log off... this is done by set presence.		Notice that there are no log on/log off... this is done by set presence.

			{{p}}

	==Things to implement for the Instant Messaging Devices==		==Things to implement for the Instant Messaging Devices==
Line 69:		Line 85:
	* Send Message - Send a message to someone on this transport.		* Send Message - Send a message to someone on this transport.
	* Set Presence - Set presence for this transport (online/away/dnd/etc)		* Set Presence - Set presence for this transport (online/away/dnd/etc)
			{{p}}

	===Instant Messaging Events===		===Instant Messaging Events===
Line 79:		Line 96:

	More to be written.		More to be written.

			{{p}}

	== Step 2. Filling in the database ==		== Step 2. Filling in the database ==
Line 85:		Line 104:

	* [[Instant Messaging Plugin Template]]		* [[Instant Messaging Plugin Template]]
	~~[[Category: Tutorials]]~~

Tschak909: /* Instant Messaging Device Commands */ lets do this

2011-01-26T18:15:32Z

Instant Messaging Device Commands: lets do this

←Older revision		Revision as of 18:15, 26 January 2011
Line 67:		Line 67:
	===Instant Messaging Device Commands===		===Instant Messaging Device Commands===

	* Log On - Log onto this transport
	* Log Off - Log off this transport
	* Send Message - Send a message to someone on this transport.		* Send Message - Send a message to someone on this transport.
	* Set Presence - Set presence for this transport (online/away/dnd/etc)		* Set Presence - Set presence for this transport (online/away/dnd/etc)

Tschak909: /* Instant Messaging Plugin Commands */ slight change.

2011-01-26T18:15:07Z

Instant Messaging Plugin Commands: slight change.

←Older revision		Revision as of 18:15, 26 January 2011
Line 1:		Line 1:
	{\| align="right"		{\| align="right"
	\| __TOC__		\| __TOC__
	\|}		\|}
Line 57:		Line 57:

	* Send Message - Sending a message to another person.		* Send Message - Sending a message to another person.
	* Log On - Log on a user to all accounts.
	* Log Off - Log off a user from all accounts.
	* Set Presence - Set presence for all accounts (Online/Offline/Away/DND)		* Set Presence - Set presence for all accounts (Online/Offline/Away/DND)

	No events need to be registered from the plugin. It doesn't send events as such, but it does intercept events from the Instant Messaging Devices.		No events need to be registered from the plugin. It doesn't send events as such, but it does intercept events from the Instant Messaging Devices.

			Notice that there are no log on/log off... this is done by set presence.

	==Things to implement for the Instant Messaging Devices==		==Things to implement for the Instant Messaging Devices==

Itsmeok at 11:35, 22 January 2009

2009-01-22T11:35:09Z

←Older revision		Revision as of 11:35, 22 January 2009
Line 87:		Line 87:

	* [[Instant Messaging Plugin Template]]		* [[Instant Messaging Plugin Template]]
			[[Category: Tutorials]]

Rwilson131 at 05:01, 1 December 2008

2008-12-01T05:01:52Z

←Older revision		Revision as of 05:01, 1 December 2008
Line 1:		Line 1:
			{\| align="right"
			\| __TOC__
			\|}
	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.		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.

Tschak909: Adding Link to IM Plugin Template.

2008-09-21T23:34:49Z

Adding Link to IM Plugin Template.

←Older revision		Revision as of 23:34, 21 September 2008
Line 78:		Line 78:

	More to be written.		More to be written.

			== Step 2. Filling in the database ==

			Before any code can be generated, the database needs to be filled in and prepared so that the system can potentially know what to expect for the plugin and their appropriate devices.

			* [[Instant Messaging Plugin Template]]

Tschak909: /* Why is the functionality split like this? */ Added necessary bit regarding the contrast from plugin to devices.

2008-09-21T23:30:10Z

Why is the functionality split like this?: Added necessary bit regarding the contrast from plugin to devices.

←Older revision		Revision as of 23:30, 21 September 2008
Line 23:		Line 23:

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

			So while the plugin acts as the high level house-wide logic, the Instant Messaging Devices provide the "workers" needed to connect to these instant messaging frameworks and do the actual work. The devices themselves emit events, and recieve commands from the Instant Messaging Plugin when something needs to be done on a particular transport. The events that are sent from the DCE devices are described below, and form the necessary notification when the plugin needs to alter data grids etc to change the UI as needed.

	The Instant_Messaging_Plugin uses the above two mentioned plugins to provide the user interface to all the orbiters in the house.		The Instant_Messaging_Plugin uses the above two mentioned plugins to provide the user interface to all the orbiters in the house.

Tschak909: added commands and more arch info.

2008-09-21T22:05:37Z

added commands and more arch info.

←Older revision		Revision as of 22:05, 21 September 2008
Line 44:		Line 44:

	Once these devices are loaded, they will attempt to do their GetConfig() routines, which, after they've done any connection/housekeeping routines that they need to do, will send events for when a new person is added, and their presence information. These events will be captured by the Instant Messaging Plugin (which registered an Event Interceptor in its Register() function.) which will act upon them, and alter data structures, etc. that will be used by the respective DataGridGenerator functions. This will be used by Orbiter, any time that the data grids are on screen.		Once these devices are loaded, they will attempt to do their GetConfig() routines, which, after they've done any connection/housekeeping routines that they need to do, will send events for when a new person is added, and their presence information. These events will be captured by the Instant Messaging Plugin (which registered an Event Interceptor in its Register() function.) which will act upon them, and alter data structures, etc. that will be used by the respective DataGridGenerator functions. This will be used by Orbiter, any time that the data grids are on screen.

			==Things to implement for Instant Messaging Plugin==

			The Instant Messaging plugin has commands of its own. These commands are typically sent from the Orbiters, however, they can be sent from anywhere within the system.

			===Instant Messaging Plugin Commands===

			* Send Message - Sending a message to another person.
			* Log On - Log on a user to all accounts.
			* Log Off - Log off a user from all accounts.
			* Set Presence - Set presence for all accounts (Online/Offline/Away/DND)

			No events need to be registered from the plugin. It doesn't send events as such, but it does intercept events from the Instant Messaging Devices.

			==Things to implement for the Instant Messaging Devices==

			===Instant Messaging Device Commands===

			* Log On - Log onto this transport
			* Log Off - Log off this transport
			* Send Message - Send a message to someone on this transport.
			* Set Presence - Set presence for this transport (online/away/dnd/etc)

			===Instant Messaging Events===

			* Message Recieved - When a message is recieved from this transport
			* Message Transmitted - When a message is transmitted to this transport
			* Buddy Added - Fired when a transport mentions that a buddy has been added, typically at logon.
			* Buddy Deleted - Fired when a transport mentions that a buddy has been removed.
			* Presence Changed - Fired when a buddy's presence changes

			More to be written.

Tschak909: Added Architectural Walk-through.

2008-09-21T20:21:29Z

Added Architectural Walk-through.

@@ Line 4: / Line 4: @@
 * Provide an instant messaging system to send messages between users of the house
-* Provide an instant messaging system to send messages between users of the house and other instant messaging networks such as AIM, Yahoo, ICQ, MSN, Jabber, and others.
+* Provide an instant messaging system to send messages between users of the house and other instant messaging networks such as AIM, Yahoo, ICQ, MSN, Jabber, and
 It was started by --[[User:Tschak909|Tschak909]] 12:22, 21 September 2008 (PDT) , but may be continued by other people during the course of its development.
@@ Line 31: / Line 32: @@
 * Local House Messaging - This device, will be a thin wrapper around DCE, that allows for instant messaging to work inside the house. Its buddy list will come directly from the in-house user list, and presence will be determined by which people have been selected as users on orbiters.
 * libPurple - This device, will be a DCE wrapper around the Pidgin Project's excellent libPurple multi-protocol Instant Messaging wrapper. Buddy lists will come from the accounts defined, and presence will be passed through from the respective protocols.

Tschak909: /* Architecture */ added the notes for which ones will be added.

2008-09-21T19:55:03Z

Architecture: added the notes for which ones will be added.

←Older revision		Revision as of 19:55, 21 September 2008
Line 24:		Line 24:

	The Instant_Messaging_Plugin uses the above two mentioned plugins to provide the user interface to all the orbiters in the house.		The Instant_Messaging_Plugin uses the above two mentioned plugins to provide the user interface to all the orbiters in the house.

			====The Two Instant Messaging Devices====

			The following two Instant Messaging Devices will be developed alongside the Instant Messaging Plugin:

			* Local House Messaging - This device, will be a thin wrapper around DCE, that allows for instant messaging to work inside the house. Its buddy list will come directly from the in-house user list, and presence will be determined by which people have been selected as users on orbiters.
			* libPurple - This device, will be a DCE wrapper around the Pidgin Project's excellent libPurple multi-protocol Instant Messaging wrapper. Buddy lists will come from the accounts defined, and presence will be passed through from the respective protocols.