Re: [Kolab-devel] Thoughts about an optional alternative to Guam

On Monday, October 31, 2016 09.39:03 Tobias Brunner wrote:
> Hi everyone,
> 
> > I personally think that Guam is too complicated for the home user.
> > It might have its place in an enterprise, with paid subscription and
> > support from Kolab Systems.
> > But for the open source user that just wants to manage his family
> > email, it is overkill.
> > Too many dependancies on Erlang and such. A new language that is not
> > mainstream. If it breaks, can I fix it myself?
> 
> We're using Guam in our commercial Hosted Kolab offering and I must say
> it's not only too complicated, it also gives us headaches regarding
> debugging, configuration, compatibility with SSL stuff, etc.
> At the end, Erlang is - IMHO - not the best decission made here. It
> makes Guam a "beast" in terms of installation (dependencies),

As I asked Timotheus: can you explain the dependencies issue please?

> configuration (file format) 

This could of course be changed to something else. Though looking around at 
the config files I already maintain elsewhere with a Kolab installation, I 
really don't understand this. Is your objection that you have to learn Yet 
Another Slightly Different Syntax? Or is the syntax really that difficult? How 
different, really, is it from something like json in structure?

> and debugging (logs).

The logs are indeed not pretty. It's something on my todol list to look for a 
pretty formatter solution. lager provides the basic infra for this, so it is 
just a matter of Doing It. Nice thing is that once a solution is identified / 
implemented, it can be applied to all the erlang/elixir components.

> It's just not ops friendly...

What would be more ops friendly for you?

> Looking at the many Kolab components, they are mostly written in Python,
> PHP and some C code. Why use another language? 

C is right out due to security and productivity. 
PHP is entirely not appropriate for the use case, given its emphasis on run-
once-the-exit architecture.
Python is possible, but gives none of the reliability and scalability that 
comes for free with the BEAM. We already see this weakness popping up in Kolab 
components written in Python.

You COULD do it in any of these languages, but it would be a lot more work and 
almost certainly have inferior results.

> I agree that we need something like Guam, or the Groupware folder
> filtering should be part of Cyrus, but that seems not so easy to
> implement I hear...

Indeed, and then it becomes cyrus specific, and folder filtering is really 
just a first application of what guam provides for. I don't see it being done 
in cyrus, tbh, though (to repeat my earlier email), I'd be very interested in 
seeing the patches.

-- 
Aaron Seigo

_______________________________________________
devel mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEABECAAYFAlgcd5wACgkQ1rcusafx20O1jwCcC6eelgoWUaxAzPCc9j6py9n6
AXgAn2nnteYskt1LbbHVU1UpKnZfYhE9
=UBWe
-----END PGP SIGNATURE-----