History

« Previous - Version 2/17 (diff) - Next » - Current version
Anonymous, 02/14/2012 11:26 am

= XMPP library candidates analysis =

In this phase the existing XMPP libraries will be analyzed and one will be chosen to be used throughout the project.

Library requirements * Written in Python (C/C++ could also be used, but a wrapper would need to be written) * Support for XMPP server (or component, details later) * Ability to use it with the current model used by SylkServer * Green threads * Callback based IO XMPP server vs XMPP component

The XMPP protocol was designed to be extended by entities called "components" which sit on the side of the server. A component is addressed with a DNS subdomain in the following form:

{{{
component.domain.tld
}}}

This mechanism is defined in [http://xmpp.org/extensions/xep-0114.html XEP-0114].

With this architecture in place deployment of additional features to an existing XMPP server doesn't require to modify it or write a new XMPP server implementation. The SIP-XMPP gateway should preferably be a component to avoid the need for implementing a full XMPP server, which would be very disruptive for existing XMPP installations that would like to benefit from the SIP gateway functionality.

Library evaluation

The following aspects were considered when evaluating a given library:

  • Met requirements stated above
  • Date of last release (is it actively maintained?)
  • Example use cases
  • Deployments in real-world scenarios
  • Perceived ability to integrate with SylkServer architecture
= SleekXMPP===

'''WIP'''

  • Plugin architecture, each XEP as a plugin
  • Client and server component support
  • Threaded model (thread based scheduler)
  • Active development

=== Wokkel ===

'''WIP'''

  • Plugin architecture, 'subprotocols' implementing different XEPs
  • Client and server component support
  • Partial support for XMPP server
  • Designed to be used with Twisted (reactor model)
  • Active development
Selected XMPP library

TODO