DesignXMPP analysis » History » Revision 8
« Previous |
Revision 8/17
(diff)
| Next »
Adrian Georgescu, 03/02/2012 10:13 AM
= Software Library Candidates Analysis =
<abbr title="DesignXMPP, DesignXMPP_analysis, DesignXMPP_arch, DesignXMPP_im, depth=2">TOC</abbr>
In this phase the existing XMPP libraries will be analyzed and one will be chosen to be used throughout the project.
Requirements * Written in Python (C/C++ could also be used, but a wrapper would need to be written) * Support for XMPP server and/or component * Ability to use it with the current model used by SylkServer * Green threads * Callback based IO XMPP server vs XMPP componentThe 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. The SIP-XMPP gateway can potentially be implemented as either a XMPP component or an standalone XMPP server.
Library EvaluationThe following aspects were considered when evaluating a given library:
- Met requirements stated above
- Is it actively maintained?
- Example use cases
- Deployments in real-world scenarios
- Perceived complexity to integrate it with SylkServer architecture
=== Wokkel ===
- Plugin architecture, 'subprotocols' implementing different XEPs
- Client and server component support
- XMPP server-to-server support (s2s)
- Designed to be used with Twisted (reactor model)
- Active development
After analyzing candidate libraries '''Wokkel''' was the chosen one for the following 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
Updated by Adrian Georgescu almost 13 years ago · 8 revisions