On 2013-01-31 09:30, Cor Bosman wrote:
On Jan 31, 2013, at 5:15 AM, "Jeroen van Meeuwen (Kolab Systems)" vanmeeuwen@kolabsys.com wrote:
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.).
One setup that works very well for us in another package is the use of apache environment variables for config management. In your apache config you'd say:
SetEnv RC_ENV production
And as a directory structure you'd have:
config/main.config.php config/db.config.php config/production/main.config.php config/production/db.config,php config/test/db.config.php
etc. If you have a set environment, it would merge that environment with the default config. This way you can set your environment using management tools like puppet/chef, without touching the rc docroot from your server management tools. And if you dont set the environment, it doesnt load anything special, thus not doing any extra IO to look for files.
Well, surely there's many ways to do this - it's almost kind of arbitrary when one ponders what could be possible.
development/test/production only go to environment staging though - We wrap around HTTP_HOST and SERVER_NAME - as production, testing and development have different DNS names / vhosts - and we host different domains / organisations - each with their own set of wishes, of course.
- responsive design. Although thats probably wishing for too much.
I'm not certain I understand what you mean by this.
Well, i suppose i could use the term 'mobile skin'. But nicer these days is if your primary skin is mobile aware and will adapt as your screen width changes using css media queries. This is called a responsive design.
http://en.wikipedia.org/wiki/Responsive_web_design. Look at this example to see what I mean http://foodsense.is/ (a random google search). Just change your browser width and see what happens.
But like I said, this is probably wishing for too much.
Right, sorry - I'm not too literate in the UI design / HE realm of the universe, but now I understand what you mean ;-)
Kind regards,
Jeroen van Meeuwen