DesignXMPP analysis » History » Revision 1
Revision 1/17
| Next »
Anonymous, 02/13/2012 03:20 PM
= 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 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 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 evaluationThe 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
TODO
=== Wokkel ===
TODO
TODO
Updated by almost 13 years ago · 1 revisions