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

Hello Aaron,

> https://docs.kolab.org/about/guam/troubleshooting.html
>
> I'm sure more can be added, but there's a start.
good to know, I was not aware of that.

>> I did make a start a while ago:
>> https://github.com/TBits/KolabScripts/wiki/Debugging-Guam
>
> Some nice things there .. would be great to merge them into the doc above. Do
> you want to do that, or should I?
I am probably not going to make it soon. If you want, please use
whatever makes sense from my wiki.

> On that note: While we would like to get rid of PHP in the long term, Python
> will not be going away. There will be more Elixir in the future, however.
> Thankfully that is MUCH more like the Python/Ruby world in terms of syntax and
> overall form, so the learning curve is less (though not entirely zero, of
> course).
So the whole kolab-webadmin is being replaced?
I like my PHP...
I am fine with Python too.

>> Perhaps we (as a community) should collect a basic set of features
>> that is expected from Kolab.
>
> Regardless of whether this results in a minimal edition or whatever, I feel
> this would have great value in that it would help Kolab Systems understand
> better what the *community* needs and wants.
>
> In a dream world this would be a broad community survey helping us all
> understand where and how people use Kolab at home or in their work.
So we could start collecting questions (perhaps on a different thread).
And then use SurveyMonkey or an alternative.

>> I have attached a patch.

>> We probably cannot submit the patch upstream,
>
> Not without making it rather more generic, no.
I wrote to the Cyrus mailing list, and got a response.
Bron suggested a more generic approach, not basing it on the Client
ID, but clients using a special LIST call.
https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2016-November/003928.html
I don't fully understand the implications for the clients we have. I
would need to try it with Roundcube first.

all the best,
Timotheus