Project

General

Profile

DesignXMPP analysis » History » Version 1

Anonymous, 02/13/2012 03:20 PM

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