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

Sat Nov 5 07:42:22 CET 2016

Hello Aaron,

thank you for your reply!

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

That is probably one reason.
You have to admit that functional programming is quite different from
the other parts of Kolab.
Yes I did learn my LISP even during school and during my studies. But
those were maximum 20 liners.
Reading https://cgit.kolab.org/guam/tree/apps/kolab_guam/src/rules/kolab_guam_rule_filter_groupware.erl
I can mostly understand it. But then there are more files in
https://cgit.kolab.org/guam/tree/apps/kolab_guam/src, and if guam
crashes, where should I start to look?
Perhaps we need a blog post explaining how to get started with
debugging Guam, or even developing for it.
I did make a start a while ago:
https://github.com/TBits/KolabScripts/wiki/Debugging-Guam

Please understand that I did not say: Guam is too complicated for the
"professional user". I said home user. And I probably meant a user
that knows a little bit of PHP and Python and packaging.
I wonder if those people from the community should need to learn Erlang.

>> 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 ...
Perhaps we (as a community) should collect a basic set of features
that is expected from Kolab.
And then work on a minimal edition of Kolab?
I just think, if we have trouble getting a release Kolab 16.1 out,
perhaps we should focus on the core?
I also say that because packaging Kolab for Distributions like Fedora,
it would be less work, and more likely to happen.
Sometimes it is better to have something than nothing at all?

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

Sorry, my words "and such" was not appropriate to what I wanted to say.
What I meant: Looking at
https://obs.kolabsys.com/project/monitor?project=Kolab%3AWinterfell
There are 64 packages with a name starting with erlang.
Only 21 packages starting with python.
26 packages starting with php.
Perhaps if erlang was uptodate in the mainstream distributions (it
seems it is in Debian, but not in the Redhat Universe), and Kolab
would not need to package it, then I would not complain. It just looks
threatening on the obs monitor page, and looks like a lot of work
maintaining those packages.
I would not want erlang bundled into one package either, because that
causes more work and responsibility for the packager.

> 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.
Perhaps you need to communicate more what you want to do with it.
I read https://exote.ch/blogs/aseigo/2015/12/10/guam-an-imap-session-filterproxy/
and came to the conclusion that only one scenario (filtering folders)
has been implemented and makes sense to a home user or small business.
For huge enterprises, I understand that you need Erlang.
If I see more practical use of Erlang that also benefits smaller
users, I am ok with it.
But otherwise, I want to balance the use of new technology (and
learning it) vs the actual benefit.

>> 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.
Perhaps because it was not packaged for CentOS7 and Fedora 23, I
thought it does not have such a big community in the open source
world.

> 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.
Oh, I am not a fan of RoR either, you might have guessed that :)
I am using RoR, if I can download it as a package and don't worry
about it. Like with Gitlab. I just don't need to go in and fix code,
because it just works. Not sure how they do it. For Kolab, that cannot
be said unfortunately. If I don't understand Kolab and the packages, I
cannot run a reliable service.

> 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.
In the future my opinion will be changed. I was talking about today.

> 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.
Thank you for the challenge. This motivated me to look at it.
I had to get back into C programming, but that worked eventually.
I have attached a patch. It certainly needs a good review, and perhaps
polishing.
I have built a package with it at
https://obs.kolabsys.com/package/show/home:tpokorra:branches:Kolab:Winterfell/cyrus-imapd

compared to
https://cgit.kolab.org/guam/tree/apps/kolab_guam/src/rules/kolab_guam_rule_filter_groupware.erl
the patch is quite small.
Does this make the Cyrus server slower than guam?
We probably cannot submit the patch upstream, but maintaining it
locally is still less work than the guam package with its extra
service. Until there are more scenarios implemented by guam that make
sense for home users and small offices.

I don't like such long emails. I am not sure I answered all your
questions. I hope you understand better what I am after.
I guess we need to have more conversations, and get the communication
flowing again!

Aaron, thank you for all you do at Kolab Systems and in the world of
Open Source!

All the best,
  Timotheus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-imapd.filterfolders.patch
Type: text/x-patch
Size: 1805 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20161105/b836cf43/attachment-0001.bin>