[Nms-cgi-devel] Various Stuff

[Dave C. <da...@da...>]

I'd like to thank Olivier for getting some discussion going on a number of
topics. Here are my opinions[1] on some of the subjects he's raised.

* Constants

It would be great if we could replace the variables with constants (because
that's what they really are). However, the idea of creating constants as
subroutines really doesn't work for me. It makes constants work too 
differently to variables (particularly with respect to interpolatation in
double-quoted strings). It would almost certainly confuse our targer
audience (not to mention new developers on the project).  The 
"use const NAME => value" pragma is simply a shortcut way of creating 
subroutine constants. Even if it was supported in 5.004_04, I would still not 
want to use it.

* New documents

Yep. Collecting those docs an putting on the web site (and, I guess, in
CVS) is a good plan. Let's kick them around for a couple of days and I'll
put them on the site towards the end of the week. Does anyone have any comments
on the docs as they stand? We're talking about the "How to become an nms
developer" and "Rules for nms code" documents that Olivier extracted from
my emails.

* Program header comments

I really like the idea of doing this, but on the other hand, I really don't
like Olivier's suggestions. I'd go for something a bit more lightweight.
Like this:

#!/usr/bin/perl -wT
#
# ProgramName.pl v1.2.3.4.5.6...
#
# This program is licensed in the same way as Perl
# itself. You are free to choose between the GNU Public
# License <http://www.gnu.org/licenses/gpl.html>  or
# the Artistic License
# <http://www.perl.com/pub/a/language/misc/Artistic.html>
#
# For a list of changes see CHANGELOG
#
# For help on configuration or installation see README
#
use strict;
use ...;
.
.
.
#
# USER CONFIGURATION SECTION
#
# Modify these to your own settings. You might have to
# contact your system administrator if you do not run
# your own web server. If the purpose of these
# parameters seems unclear, please see the README file.
#
my $param   = 'stuff';    # Will be used for stuff
my $baseurl = '/var/www'; # Server's web documents directory
my ...;
.
.
.
#
# END USER CONFIGURATION
# (no user servicable parts beyond here)
#

* CHANGELOG file

I totally agree that tha changelog will soon be too big to have in the
code files. The idea of a separate CHANGELOG file sounds great to me. If
a CVS guru could point me at the magic invocation to create the CHANGELOG
file auto-magically as part of the release process then I'd be even
happier.


Hope that makes sense. All comments welcome.

Dave...
[not speaking ex-cathredra]

[1] And that's all they are - my _opinions_. I'm not laying down the law
here.

-- 

  Don't dream it... be it