DesignXMPP analysis
Version 2 (Anonymous, 02/14/2012 11:26 am)
| 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 | ||
| 37 | 2 | '''WIP''' |
|
| 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 | 2 | ||
| 44 | 1 | === Wokkel === |
|
| 45 | 1 | ||
| 46 | 2 | '''WIP''' |
|
| 47 | 2 | ||
| 48 | 2 | * Plugin architecture, 'subprotocols' implementing different XEPs |
|
| 49 | 2 | * Client and server component support |
|
| 50 | 2 | * Partial support for XMPP server |
|
| 51 | 2 | * Designed to be used with Twisted (reactor model) |
|
| 52 | 2 | * Active development |
|
| 53 | 2 | ||
| 54 | 1 | == Selected XMPP library == |
|
| 55 | 2 | ||
| 56 | 1 | TODO |