DesignXMPP analysis » History » Version 11
Adrian Georgescu, 03/07/2012 09:18 AM
| 1 | 10 | Adrian Georgescu | = Software Candidates Analysis = |
|---|---|---|---|
| 2 | 1 | ||
| 3 | 11 | Adrian Georgescu | [[TOC(DesignXMPP, DesignXMPP_analysis, DesignXMPP_arch, DesignXMPP_im, DesignXMPP_presence, DesignXMPP_jingle, DesignXMPP_ft, 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 | |||
| 7 | 8 | Adrian Georgescu | == Requirements == |
| 8 | 1 | ||
| 9 | * Written in Python (C/C++ could also be used, but a wrapper would need to be written) |
||
| 10 | 7 | Adrian Georgescu | * Support for XMPP server and/or component |
| 11 | 1 | * Ability to use it with the current model used by SylkServer |
|
| 12 | * Green threads |
||
| 13 | * Callback based IO |
||
| 14 | |||
| 15 | == XMPP server vs XMPP component |
||
| 16 | |||
| 17 | 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 | |||
| 19 | {{{ |
||
| 20 | component.domain.tld |
||
| 21 | }}} |
||
| 22 | |||
| 23 | This mechanism is defined in [http://xmpp.org/extensions/xep-0114.html XEP-0114]. |
||
| 24 | |||
| 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 | 7 | Adrian Georgescu | == Library Evaluation == |
| 28 | 1 | ||
| 29 | The following aspects were considered when evaluating a given library: |
||
| 30 | |||
| 31 | * Met requirements stated above |
||
| 32 | 3 | * Is it actively maintained? |
|
| 33 | 1 | * Example use cases |
|
| 34 | * Deployments in real-world scenarios |
||
| 35 | 3 | * Perceived complexity to integrate it with SylkServer architecture |
|
| 36 | 9 | Adrian Georgescu | |
| 37 | List on xmpp.org http://xmpp.org/xmpp-software/libraries/ |
||
| 38 | 1 | ||
| 39 | 2 | === SleekXMPP=== |
|
| 40 | |||
| 41 | 9 | Adrian Georgescu | http://github.com/fritzy/SleekXMPP |
| 42 | |||
| 43 | |||
| 44 | 2 | * Plugin architecture, each XEP as a plugin |
|
| 45 | * Client and server component support |
||
| 46 | * Threaded model (thread based scheduler) |
||
| 47 | * Active development |
||
| 48 | 1 | ||
| 49 | === Wokkel === |
||
| 50 | 2 | ||
| 51 | 9 | Adrian Georgescu | http://wokkel.ik.nu/ |
| 52 | |||
| 53 | 1 | * Plugin architecture, 'subprotocols' implementing different XEPs |
|
| 54 | * Client and server component support |
||
| 55 | 3 | * XMPP server-to-server support (s2s) |
|
| 56 | 1 | * Designed to be used with Twisted (reactor model) |
|
| 57 | 2 | * Active development |
|
| 58 | |||
| 59 | == Selected XMPP library == |
||
| 60 | |||
| 61 | 7 | Adrian Georgescu | After analyzing candidate libraries '''Wokkel''' was the chosen one for the following reasons: |
| 62 | 3 | ||
| 63 | * Implemented on top of Twisted, which makes integration with SylkServer straightforward |
||
| 64 | * Support for both component and XMPP server models, allowing for flexibility in implementation |
||
| 65 | 9 | Adrian Georgescu | |
| 66 | == Selected SIP Library == |
||
| 67 | |||
| 68 | SIP SIMPLE SDK http://sipsimpleclient.com |