DesignXMPP analysis

Version 1 (Anonymous, 02/13/2012 03:20 pm)

1 1
= XMPP library candidates analysis =
2 1
3 1
In this phase the existing XMPP libraries will be analyzed and one will be chosen to be used throughout the project.
4 1
5 1
== Library requirements ==
6 1
7 1
 * Written in Python (C/C++ could also be used, but a wrapper would need to be written)
8 1
 * Support for XMPP server (or component, details later)
9 1
 * Ability to use it with the current model used by SylkServer
10 1
  * Green threads
11 1
  * Callback based IO
12 1
13 1
== XMPP server vs XMPP component
14 1
15 1
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:
16 1
17 1
{{{
18 1
component.domain.tld
19 1
}}}
20 1
21 1
This mechanism is defined in [http://xmpp.org/extensions/xep-0114.html XEP-0114].
22 1
23 1
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.
24 1
25 1
== Library evaluation ==
26 1
27 1
The following aspects were considered when evaluating a given library:
28 1
29 1
 * Met requirements stated above
30 1
 * Date of last release (is it actively maintained?)
31 1
 * Example use cases
32 1
 * Deployments in real-world scenarios
33 1
 * Perceived ability to integrate with SylkServer architecture
34 1
 
35 1
=== SleekXMPP===
36 1
TODO
37 1
38 1
=== Wokkel ===
39 1
TODO
40 1
41 1
== Selected XMPP library ==
42 1
TODO