OpenBand

XMPPFramework version 1 was a cluster of modules designed to provide XMPP functionality to the Drupal platform. The module cluster was originally designed as just one module: XMPPClient. This module was designed to provide a Thin Web Client tightly associated with Drupal so that users could launch it from their Drupal instance without having to enter their password or install any third-party applications onto their machine/device. Once this module was completed we realized there was a need for even more integration into the Drupal platform, and from this need arose the XMPPFramework module cluster.

Current Implementation
In its current implementation, the XMPPFramework module has the following modules integrated into it:

• XMPPFramework – module providing high level commands that other modules can access.
• XMPP Client – module providing XWChat Thin Web Client
• XMPP Relationships – module tying user relationships to XMPP
• XMPP VCard – module tying user content profiles to XMPP VCard
• XMPP Roster – module tying XMPP Roster to user relationships
• XMPP Node MUC – module associating groups with Mucs
• XMPP API – provide pure XMPP transport layer for the framework
• XMPP XMLRPC – provide pure XMPRPC transport layer for the framework
• XMPP Messaging – provide interface to the messaging framework
• XMPP Notifications – provide interface to the notifications framework

Future Road Map for XMPP Framework
In the current implementation the user information is stored in the XMPP Client module (it was the first module to be developed and we did not expect to have a cluster of modules for XMPP integration when we developed it). This functionality will be moved into its own module and called XMPP User. The XMPP User module will remove all of the user functionality from the XMPP Client module allowing the XMPP Client module to simply provide a thin web client for Drupal.

The XMPP User module will be compact and behind the scenes with no visible user interfaces. It will provide an administration screen which will allow the administrator to determine if the system should inject the XMPPClient JID and Password fields into the user edit form so that people can set the password and alter their JIDs based off their preferences.

XMPP XMLRPC will be updated so that we can support an OpenFire xmlrpc module. We’ll be writing it in conjunction with making sure we can utilize ejabberd’s new approach to xmlrpc, since we currently use mod_xmlrpc which is being depreciated. XMPP XMLRPC might receive more commands as we extend the capabilities of the XMPP Framework however the ultimate approach would be to do everything in pure XMPP if available.

XMPP API will be updated to utilize a completely different connection protocol. Currently the module does one connection per command so if we have more than one command occurring during the same page load the XMPP API will create “X” number of requests where “X” is the number of XMPP Framework commands that have been called in the page load.

XMPP Client will have a lot of its functionality trimmed and put into the XMPP User module where applicable. All of the user loading, checking for JIDs and other XMPP related helper functions will be removed from this module as will the hooks into user login with regard to catching the users password so we can store it for retrieval when logging into the Web Thin Client.

Web Thin Client will be optimized and updated based off the latest XEP protocols that are being released by the XMPP Foundation and also based off relevant user requests.

Overall the XMPP Framework as it stands was a good staging area for determining the coming future needs for Drupal and provided us a solid platform for building XMPP functionality into Drupal. We’re excited by the current user base and hope that the next version of XMPP Framework will be even more accessible to the community.