DesignXMPP analysis

Version 4 (Anonymous, 02/29/2012 12:33 pm)

1 1
= XMPP library candidates analysis =
2 1
3 4
[[TOC(DesignXMPP_analysis, depth=2)]]
4 4
5 1
In this phase the existing XMPP libraries will be analyzed and one will be chosen to be used throughout the project.
6 1
7 1
== Library requirements ==
8 1
9 1
 * Written in Python (C/C++ could also be used, but a wrapper would need to be written)
10 1
 * Support for XMPP server (or component, details later)
11 1
 * Ability to use it with the current model used by SylkServer
12 1
  * Green threads
13 1
  * Callback based IO
14 1
15 1
== XMPP server vs XMPP component
16 1
17 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:
18 1
19 1
{{{
20 1
component.domain.tld
21 1
}}}
22 1
23 1
This mechanism is defined in [http://xmpp.org/extensions/xep-0114.html XEP-0114].
24 1
25 3
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.
26 1
27 1
== Library evaluation ==
28 1
29 1
The following aspects were considered when evaluating a given library:
30 1
31 1
 * Met requirements stated above
32 3
 * Is it actively maintained?
33 1
 * Example use cases
34 1
 * Deployments in real-world scenarios
35 3
 * Perceived complexity to integrate it with SylkServer architecture
36 1
 
37 2
=== SleekXMPP===
38 2
39 2
 * Plugin architecture, each XEP as a plugin
40 2
 * Client and server component support
41 2
 * Threaded model (thread based scheduler)
42 2
 * Active development
43 1
44 1
=== Wokkel ===
45 2
46 1
 * Plugin architecture, 'subprotocols' implementing different XEPs
47 1
 * Client and server component support
48 3
 * XMPP server-to-server support (s2s)
49 1
 * Designed to be used with Twisted (reactor model)
50 2
 * Active development
51 2
52 2
== Selected XMPP library ==
53 2
54 3
After analyzing candidate libraries '''Wokkel''' was the chosen one. Reasons:
55 3
56 3
 * Implemented on top of Twisted, which makes integration with SylkServer straightforward
57 3
 * Support for both component and XMPP server models, allowing for flexibility in implementation