SIP SIMPLE Client SDK

= 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