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

[Aaron J. Seigo]

On Saturday, October 29, 2016 08.17:06 Timotheus Pokorra wrote:
> (question: should I post this on kolab hub instead? where are most
> developers reading and participating???)

both ...

> I personally think that Guam is too complicated for the home user

How do you feel it is too complicated?

I ask for two reasons:

a) many things in Kolab are "complicated", as in "requires to learn how to set 
it up, install, etc."; but they are, due to being around for a while, are more 
familiar to people. So when you say Guam is complicated, I wonder about 
newness and complexity relative to other components

b) anything can be improved if understood. So if you can define what makes it 
(feel?) complex for you, perhaps something can be done about it.

> But for the open source user that just wants to manage his family
> email, it is overkill.

I would say that's true of a lot of things in Kolab, though ...

> Too many dependancies on Erlang and such. 

.. that is really its ONLY dependency. Everything else, like openssl, is 
already required for Kolab. So .. I don't understand "too many" dependencies 
.. unless what you mean is "Erlang is a new dependency, and any new dependency 
is undesired"?

If so, can you explain why?

There are very good reasons for using Erlang here, and we are producing more 
code using BEAM (the Erlang equivalent of Java's JVM) languages ... so I'd 
like to understand this.

> A new language that is not mainstream. 

It is not as mainstream as C, PHP or Javascript .. but none of those are 
appropriate to the tasks here. But it is not fringe at all. WhatApp, 
changelog.com, bleacher report, and hundreds of others many will know by name 
use BEAM languages. It is the core of ejabberd, couchdb, and many other 
packages.

It has been around for ~30 years now, and is very actively  developed and 
maintained with a vibrant community turning out exciting things like the 
Pheonix Framework for web apps that handily outdoes RoR in terms of 
performance (and IME manageability) while maintaining productivity and 
increasing clarity.

So .. that "not mainstream" idea is not really accurate iho.

> If it breaks, can I fix it myself?

Probably you can. It is not rocket science.

That said, I'm not sure how many of our home users can fix cyrus imap (C) or 
many of the python packages Kolab relies on.

> The only use case that is implemented currently is
> filter_groupware_folders. That is actually a good feature. But I
> wonder if we cannot patch Cyrus (and Dovecot) to recognise the client
> and only publish folders that the client understands. Of course that
> patch needs to go upstream when it works.

Sure, one could patch the entire world of IMAP servers .. or use a proxy to do 
this and do it one place.

It also avoids having to pull in tight integration with other components into 
the IMAP server (something I expect to happen in future as more rulesets are 
added to guam), allowing the IMAP server to do One Thing Well.

So of course you can do it in the imap server. Only you are now dealing with 
C, which is not only lower productivity but a greater security risk and rather 
more work to get to be performant.

> What do people think?

It really is not a question of "can you" (one can do almost anything with 
enough effort, after all), but what the effort required and results out the 
other side are.

I would be interested in seeing your patches to cyrus for this.

-- 
Aaron Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20161104/21deca8e/attachment.sig>