On 2013-01-26 14:31, Cor Bosman wrote:
oops, forgot the wish list. As a maintainer of a roundcube installation i miss:
- better config management. Even if it were just a _local file that
would override the default config. I know about virtual host configs, but for us they dont quite work as we have a loadbalanced setup, but at the same time id like to reach any of the individual servers as well to check problems with a specific server. With test servers, development servers, etc etc this could easily get to dozens of servers.
Amen - we run in to these scaling issues (w/ configuration) ourselves as well. We do not use the vhost configuration mechanism, but instead:
have defaults in the configuration file,
include a vhost specific configuration file (sometimes we
require_once() it, sometimes we @include_once() perhaps with a test to see whether it exists at all),
(such as 'dont_override' parameters and plugins that we require for all vhosts, etc.).
- responsive design. Although thats probably wishing for too much.
I'm not certain I understand what you mean by this.
- an editor for sieve. we allow all kinds of sieve clients to access
the sieve server, including writing your own sieve scripts from scratch. Would be cool if roundcube would detect that IT didnt make the sieve script, and if it cant decode the script, at least show you an editor screen with the whole script. The potential for script mangling is very present now.
This is another thing we've run in to in the past. There's a clear danger between all sorts of different sieve script editors that do not understand what another has written out, let alone something manually crafted, let alone that most sieve editors do not understand a part of the (set of) sieve scripts may have been written out by a management suite (think: corporate mandatory rules for groups of users). I reckon part of the problem is in the liberty or loosely defined Sieve script syntax, though, and it has proven very difficult to really do anything about it.
Kind regards,
Jeroen van Meeuwen