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 |