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

Tobias Brunner <[email protected]> Thu, 24 Nov 2016 10:46:50 +0100
Newsgroups	gmane.comp.kde.devel.kolab
Message-ID	<f56a8601-27a6-803c-0b74-384819382a65__11638.6942485862$1479980834$gmane$org@tobru.ch>
Hi Aaron,

> On 22.11.2016 10:20, Aaron Seigo wrote:
>> Need to look at the integration, multi-tennant, and scalability
>> stories. Will do so today.
> 
> Now it's coming back to me .. :) I had looked at this quite some time
> ago, and I begin to recall my concerns.
> 
> LDAP integration is essentially "copy the users from LDAP periodically
> into our own database". Not particularly pretty, tbh. And as usual, the
> LDAP auth flexibility is very simplistic; definitely good enough for
> single-site installation, certainly a typical use case.
> 
> It also uses mongo db. Not a good option for us at all. (Happy to go
> into why that is in another thread if anyone cares :) pgsql support has
> been asked for for some time, still isn't there. This is concerning.
> 
> Javascript throughout is a little concerning for a real-time application
> that needs to both scale and have high uptime; that has not yet been
> shown to be server-side javascript's strengths. (It has strengths, but
> they lay elsewhere.)
> 
> It's a large and complex application, with dozens of packages and
> packing some 140kloc. They picked a platform on which they have to
> implement a lot from the ground up.
> 
> HA and clustering is somewhere between "not easy and untested" and "not
> existent". This is something we could perhaps contribute to. It's
> something we get for free, and very well tested, with Phoenix pub/sub,
> however.
> 
> 
> 
> Better things:
> 
> Federation is done via matrix, which is a nice touch.
> 
> The mobile and desktop app support is not great, but improving.
> Apparently libpurple has (some?) support for it now, and there is an
> xmpp bridge, so while you perhaps don't get 100% feature parity, it
> seems passable.
> 
> The integration story is not horrible, though. The REST API is
> sufficient for straight-forward use cases (e.g. "add chat to
> collaborative editing", "launch a chat room from a calendar invite"),
> but deeper integration seems to require adopting the meteor app model
> more broadly. So this is actually a fairly decent aspect.
> 
> 
> It's a bit unfortunate as it is actively developed and has a rather
> remarkable feature set. The downsides are just very difficult to swallow
> for our target uses and deployments :(

Thanks a lot for your in-depth review! Really appreciate that.
We are currently in a state where many new chat apps are arising, like
Mattermost, Rocket.Chat, Matrix, ... All of them are so new that they
need a lot more time to evolve. This will then also be the case with the
new Kolab chat server, it will also take a long time to evolve.

Cheers and looking forward to the new product,
Tobias

_______________________________________________
devel mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/devel
signature.asc (application/pgp-signature, 825 B)