[Kolab-devel] kolab and real-time communication (chat, etc)

Mihai Badici mihai at badici.ro
Mon Nov 21 18:29:47 CET 2016


> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.

I can understood this point of view, however it is not very clear for me what 
do you mean by "integrated feature in kolab?" From my point of view, kolab is 
pretty modular, and i think it is better to stay modular. At first view, i see 
only two point of connection of jabber to kolab: first it is LDAP ( ejabberd 
support is pretty week indeed here) and Roundcube. If you want to integrate 
some part in a fat client, we need to change the fat client. ( I like fat 
clients, i'm old style, i even use kopete with google talk when i don't need 
voice :) )  But I don't see a problem using let's say TB or kmail  or outlook 
for mail and kopete, or pidgin or let's say jitsi who has a full stack for 
audio/video for chat.   

> 
> The other set of problems come from XMPP itself. Frankly, it is a
> horrible protocol.
> 
> 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.
Well, all of that is true, but i'm affraid if it tooks years to have a decent 
xmpp setup ( and we can't say we have it now in fact)   could take years again 
to change . But, if you are ready for that, ok, maybe the problem was the 
protocol itself.

> 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.
I'm a little afraid you try to rewrite Exchange. There were in the past tons 
of fully integrated web based collaborative solution, i don't remember none of 
them. I'm interested in kolab precisely because it is standard, modular and 
use well tested components. It has a nice webmail but works alo with Outlook, 
works with ActiveSync but also with a simple imap client and so on. If you are 
aware of that and took all aspects in consideration, i'm probably wrong, 
because I agree with you sometime we need to rid of old stuff...



More information about the devel mailing list