[Nms-cgi-devel] Re: Configuration (was Re: Constants (was Re: [Nms-cgi-devel] Various Stuff);)

[Joseph F. R. <rya...@os...>]

At 08:00 PM 1/30/2002 +0000, you wrote:
>On Wed, 30 Jan 2002, Joseph F. Ryan wrote:
>
> >
> > Tell me; how many of you use constants for configuration stuff in your own
> > Perl code?  It's NEVER done.  The constant pragma isn't even used much, and
> > that is in the core.
> >
>
>I would say that NEVER is a little strong perhaps.  For myself I am
>unlikely to ever put configuration in the code itself, and where I do it
>is likely to be in some Config.pm with accessor methods to the
>configuration items, but 'constant' does have its place when you are
>dealing with stuff that really is constant like 'PI' or 'TOES_PER_FOOT'.

some of us might be tempted to


use Math::Complex qw(trig);


to export pi in a bit saner manner ;)

Anyways, I wasn't talking about actual constants; I was talking about 
config stuff. Like you said; if this were a normal project, it would be 
stored in some sort of db or config file.  However, this isn't a normal 
project, which leaves us with a few options:

1.) Store the Config inline in the file
2.) Store the Config in an outside file

Each have their drawbacks:
1.) When it is inline, there runs a risk that the user will mess up the 
code.  Plus, its bad practice and looks ugly.
2.) Possibly more confusing for the user.

So which do we use?
Well, how about both?

What if we have defaults inline in the file, and then have an outside 
config file the user can change?  The defaults would be the fail safe if 
the user screws up the config, while the config will contain what is user 
defined.  We can parse the config, and if that fails, the defaults are loaded.

I was also thinking that we really couldn't have a program create the 
config for us.  There is a problem with each of the options:

1.) A cgi-script to create the config would be a HUGE security hole
2.) A compiled C script would not be cross-platform
3.) Not all users have shell access

Therefore, I think a manually edited config is the only solution...

Opinions? :)

>We all use manifest constants from modules like Socket or Fcntl and these
>are superficially similar to what 'constant' does (Ok, it gets a little
>different if you look too closely under the bonnet - but hey, don't do
>that :)
>
>What I really want to discuss is the configuration mechanism in its
>entirety: with the exception perhaps of the message storage mechanism
>employed by wwwboard, the configuration-by-editing-the-program-file is one
>of the nastiest legacies from the original code that we seem compelled to
>keep; but this, as we have discussed already, is more likely to lead to
>error and confusion in the hands of a non-programming 'webmaster' than
>anything else.  OK, its agreed that we have to support the possibility of
>the end-user upgrading their FormMail.pl or whatever by simply uploading a
>new program file with the configuration details changed, but are these
>people really that useless that they can't edit and upload a separate
>configuration file ?
>
>
>I'm thinking that for the Green field sites that perhaps we should have an
>'NMS COnfigurator' which, whilst it needs to be edited once itself, will
>infact write the configuration of all the other NMS programs ...
>
>
>Train Journey over ... discuss :)
>
>
>/J\
>--
>Jonathan Stowe                      |
><http://www.gellyfish.com>          |      This space for rent
>                                     |
>
>
>_______________________________________________
>Nms-cgi-devel mailing list
>Nms...@li...
>https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel