[mnet-devel] De-confusing config

[Jim McCoy]

The Mnet config carries with it a bit too much baggage from MojoNation, 
when we had no idea
if certain things would work and needed to be able to make changes 
quickly without pushing out
a new build.  Unfortunately this seems to have been carried forward 
into Mnet.

With too many mods to support hacking and testing, we are adding enough 
rope to let a user
hang themselves. By cutting down on the number of config options it is 
possible to make
the system a little more stable and cut down on the config mess. I 
think most config
options can be divided into one of three categories that I am calling 
constants, resources,
and settings.  An easy way to think of these categories is that 
constants are build specific,
resources are installation specific, and settings are invocation 
specific.


Constants
     -what these are should be obvious
     -things that might be changed between builds but are user 
configurable
     -platform independant settings

     =Constants would be put into a Constants.py module that could be 
imported as necessary

Resources
     -where to find various resources that are local to a particular 
host/user and platform info
         -info a node needs to operate within the collective network
         -sufficient info to operate on this local host with the 
installation default settings
     -default paths and directories for this particular installation 
(which are _not_ platform
      independant)
     -this info may be determined using local API calls at runtime, but 
how this info is
      gathered is unlikely to change once a node is installed and 
running; with the exception
      of environment specific data like user name (which the OS can use 
to determine "home dir", etc)
      the resources should be sufficient to run a node
     -changes may require a user to use a special tool (configtool) or 
via the UI

     =Resources would consist of a LocalResources.py module that has the 
functions necessary
      to pull in the info and possibly a config file that is written at 
installation time.

Settings
     -thing the users can change on the fly or between invocations that 
alter behavior
     -may be used to bootstrap or supplement data in Resources (e.g. 
changing "root" paths, etc.)
     -traditional config file or OS standard software config tool 
(registry, OS X plists,
      node.conf, etc.)
     -user can override with command-line options or environment 
variables if the platform
      supports them
     -max of ten settings, fewer is better

     =Settings will be set via the UI or CLI for the node and stored 
where other prefs are
      stored according to the convention of the OS


Does this breakdown seem logical?  If so I plan on going through the 
current config stuff and
seeing what can be pulled into various categories and making some 
first-pass groupings of variables.
I will also try to track down where various settings are being called 
to see if some things
are better put into the files that use them and should not be a config 
setting.

Jim




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel