DesignXMPP analysis
Version 2 (Anonymous, 02/14/2012 11:26 am) → Version 3/17 (Anonymous, 02/29/2012 11:27 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. it or write a new XMPP server implementation. The SIP-XMPP gateway can potentially should preferably be implemented as either a XMPP component or an standalone to avoid the need for implementing a full XMPP server. 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
* Is Date of last release (is it actively maintained? maintained?)
* Example use cases
* Deployments in real-world scenarios
* Perceived complexity ability to integrate it 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-to-server support (s2s) server
* Designed to be used with Twisted (reactor model)
* Active development
== Selected XMPP library ==
After analyzing candidate libraries '''Wokkel''' was the chosen one. Reasons:
* Implemented on top of Twisted, which makes integration with SylkServer straightforward
* Support for both component and XMPP server models, allowing for flexibility in implementation
TODO
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. it or write a new XMPP server implementation. The SIP-XMPP gateway can potentially should preferably be implemented as either a XMPP component or an standalone to avoid the need for implementing a full XMPP server. 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
* Is Date of last release (is it actively maintained? maintained?)
* Example use cases
* Deployments in real-world scenarios
* Perceived complexity ability to integrate it 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-to-server support (s2s) server
* Designed to be used with Twisted (reactor model)
* Active development
== Selected XMPP library ==
After analyzing candidate libraries '''Wokkel''' was the chosen one. Reasons:
* Implemented on top of Twisted, which makes integration with SylkServer straightforward
* Support for both component and XMPP server models, allowing for flexibility in implementation
TODO