
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p>On 21.11.2016 10:52, Mihai Badici wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->

<p>I still use in some installations the old converse plugin with ejabberd or openfire (the second look more advanced ldap side). The plugin need to be changed for sure but you want to change the server too? </p>

</blockquote>

<div>"Want" is probably not the right word. The challenges with the existing XMPP servers lay in two places.</div>

<div> </div>

<div>First, they are not small, easy-to-integrate systems. The best we could manage is a jabber server that connects to a given ldap system. This would not really give us real-time communication in Kolab, it would give us real-time communication alongside Kolab.</div>

<div> </div>

<div>As an example: ejabberd / mongooseIM (a fork of ejabberd), probably the best option in terms of scalability and features, does not provide a way to map to Kolab's multi-tennant concepts.</div>

<div> </div>

<div>Adding other features and integration points (such as creation of chat areas for document editing) would be quite a bit of work. Particularly when we eventually add the ability to do one-time anonymous invite links.</div>

<div> </div>

<div>We want to provide real-time communication as an integrated feature in Kolab, not as something just bolted on to the side. And we want to do that in a simple to manage way. Kolab is already complex enough. Adding "now just manage this entire other complex server as well" on to the side of that is troubling.</div>

<div> </div>

<div> </div>

<div>The other set of problems come from XMPP itself. Frankly, it is a horrible protocol.</div>

<div> </div>

<div>It regularly routes messages to devices inappropriately (several of us here have jabber on phones, tablets, multiple computers .. all potentially logged in), has elected to elevate federation over other features when the implementations might conflict (despite the fact that for all intents and purposes a federated XMPP world is well and dead at this point), does not provide support for end-to-end encryption except as an add-on hack that requires clients to do absolutely everything (meaning client disparity is the norm there), etc. etc. etc.</div>

<div> </div>

<div>All of this is wrapped in a verbose XML stream, for which existing implementations offer limited means of adding to. mongoose IM is probably leading the way there at this point, but it still is not sufficient for our needs.</div>

<div> </div>

<div> </div>

<div>So we get to choose:</div>

<div> </div>

<div> a) something existing and proven which is quick to slap on right now to get us XMPP (only)</div>

<div> b) something that is easy to install and manage which we can integrate perfectly with Kolab's features today and in the future, and which will eventually deliver basic XMPP</div>

<div> </div>

<div>We have chosen ease of management and integration over a quick fix. Put another way, we have elected to provide an amazing user experience even if it means a bit more work.</div>

<div> </div>

<div>-- <br />

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Aaron Seigo</div>

</div>

</body></html>