Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Message-ID: <1310130318.1114946764254.JavaMail.jira@ajax.apache.org>
Date: Sun, 1 May 2005 13:26:04 +0200 (CEST)
From: "Leo Simons (JIRA)" <general@gump.apache.org>
To: general@gump.apache.org
Subject: [jira] Created: (GUMP-125) Flexible way to configure gump in modern
 unix-like fashion
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Flexible way to configure gump in modern unix-like fashion
----------------------------------------------------------

         Key: GUMP-125
         URL: http://issues.apache.org/jira/browse/GUMP-125
     Project: Gump
        Type: New Feature
  Components: Python-based Gump  
    Versions: Gump3-alpha-6    
    Reporter: Leo Simons
     Fix For: Gump3-alpha-6


Gump2 is configured in the <workspace/> just like Java-Gump was. Gump3 is currently configured through environment variables and the command line (sourcing a shell script for custom settings).

We should provide a logical and modern way to configure gump through

  /etc/gump3

and

  $HOME/.gump3

directories where you can safely store configuration data related to the machine or the environment (ie, database to use, JAVA_HOME to use, ...).

A nice example of an application with flexible configuration support is exim, another one is spamassassin, yet another one is apache2 as provided for debian. Things I would like to see:

 * conf.d directories to allow spliting config
 * per-profile config as well as per-machine config
 * use python's features as much as possible for config features and intelligence
 * installation of default config files with lots of comments so no RTFM is needed

One advantage of the gump3 "gump" script is that it has no particular trouble firing up jetty (for dynagump) or apache (for webgump). We really need to keep that flexibility, meaning it might make sense to have the configuration parsing set up almost totally seperately from the rest of gump. We could even consider something that reads the environment and the config files and then generates a really-long-commandline or temporary-shell-script. It could be a reusable python tool :-)

Or maybe that's a bad idea. We'll see.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org