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),
- (re-)apply settings we find are mandatory and are not to be changed
(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
--
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com
pgp: 9342 BF08
_______________________________________________
Roundcube Development discussion mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/dev