nms-cgi-devel — Developers discussion for NMS CGI programs

Re: [Nms-cgi-devel] Proposed programs' header skeleton

[Olivier D. <dr...@sh...>]

On Mon, Jan 28, 2002 at 08:51:14PM -0500, Joseph F. Ryan wrote:
> Eww... this is very ugly, and very similar to the way Matt Wright did 
> it.  Flower boxes are reminiscent of BASIC; I don't know of anyone who 
> still uses them in production code, especially perl code.  I think the way 
> we have the configuration section delimited now is fine.

I'm confused... Do we want those scripts to be as much as humainly
possible like Matt Wright's or not?

As for flower boxes, they make things clear. And as many newbies will
tell you they like things when it's clear. I may be wrong, but I seem to
recall this project to be for non-technical people who know very little
about programming, and probably even less about Perl. I'm new to this
project so please, let me know if my stream of thought is going in the
wrong direction.

Also, another reason why I don't like the way it is now is because of
the very long long long long long log at the beginning of each programs.
I think logs belongs in a seperate file, but again, that's just my
opinion. If nobody else agrees (like in the case of constants) then
we'll leave it this way.

> The necessary information is in the README.  In fact, I think its 
> harmful to put the descriptions of the config in the script itself, as a 
> lazy user may attempt to decipher the variables just from the description 
> and never look at the README for more complete explanations.

I agree with that. I put short brief comments by the config parameters
but I think having the warning at the top is enough to direct users who
don't understand to the README file.

-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

[Nms-cgi-devel] Proposed programs' header skeleton

[Olivier D. <dr...@sh...>]

I'd like to make a proposition for the header of each scripts.

<<<<<<
#!/usr/bin/perl -wT

########################################################
# Program information ##################################
########################################################
# 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
########################################################
# DO NOT CHANGE! #######################################
########################################################
#
use strict;
use ...;
.
.
.
#
########################################################
# Configuration ########################################
########################################################
# 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 ...;
.
.
.
#
########################################################
# Main program #########################################
########################################################
# From now on, you should not have to change anything in
# order for the program to work. If the program does not
# work, review your configuration above or contact your
# system administrator.
#

*code*
>>>>>>

Let me know what you think. The only thing I feel uncomfortable with is
the license declaration which I took from the FAQ. The rest, I think
would look much better than we have right now. I intend to implement
those changes myself if everyone agrees with them.

-Oli


-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

RE: [Nms-cgi-devel] Open question on variable/constants

[Wizard <wi...@ne...>]

> Would the "use constant CONSTANTNAME => VALUE" be more efficient? As
> efficient as scalars, arrays or hash?
No, all that 'use constant X' does is create an anonymous subroutine 'X'.
It's equivalent to:
*X = sub () { <value> };
which is basically what you are suggesting. 'use constant' also isn't
supported in 5.004x, which I believe is the target.

> Maybe I'm pushing it too far, but I thought the aim of this project was
> to provide better quality (in delivering a service, in security and as
> a coding model) In my opinion, allowing what should be constants to be
> modified isn't a very secure practice. Would you do the same in C?

Provided that the code is written well, it shouldn't be possible to modify
ANY variables that aren't exposed through CGI (and I should hope that only
the ones that are necessary are).

The idea that Perl doesn't really have any constants is an ongoing debate
(and the reason for the 'use constants' hack). I personally believe that
Perl manages just fine without them, and provided the developer uses due
caution in the code, it really is only a issue of resources. As far as C
goes, It's an entirely different language, and not really a practical
comparison (Perl say's "What's a macro?") ;-)

Grant M.

Re: [Nms-cgi-devel] Open question on variable/constants

[Olivier D. <dr...@sh...>]

On Mon, Jan 28, 2002 at 11:42:58PM +0000, Nick Cleaton wrote:
> The big problem (with both constants and subs) is that it makes
> the config section of the script look a bit different, and we're
> aiming to make it very easy for users with no technical skills to
> change from Matt's version to ours by copying their config over.

True. But I think if it *looks* like it, then normal people will
realize that we're just making things "better" because MWS are "bad"
which is also, I think, one of the goal of this project.

On the other hand, at least for formmail--I haven't looked at
any others yet--the configuration setting is *MUCH* different from MWS.
Putting 3-4 line comments between each config variables resulting in
about 4 pages of config for about 5-10 parameters definetly makes it very
*HARD* for newbies. And what is the configuration isn't clear either.
There are impossible to notice "Configuration" and "End Configuration"
comments burried under a pile of other comments which really belong in
the README. I've been a newbie not so long ago and MWS, although bad,
had all of the config parameters together, one line after the other; all
of this enclosed in very visible "Configuration - this is all you need
to modify to get the script working" comments placed near the top of the
script; not after a few pages of log, which I think belong in a seperate
file.

I'm not trying to critisize anybody's work here. I know that nothing is
finished yet--in fact most scripts have alpha or beta attached to them.
I'm simply trying to make a point that using "use constant" instead of
scalar is a better way of doing thing, and I don't see it being an
issue for readability and MWS users' friendliness. Oppositely, I would
see it as more user friendly.

As a diet-coke of newbie I'd say that if comments are clear, you can
put things any way you want.

-Oli


-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

Re: [Nms-cgi-devel] Open question on variable/constants

[Nick C. <ni...@cl...>]

On Mon, Jan 28, 2002 at 06:34:07PM -0500, Olivier Dragon wrote:
> On Mon, Jan 28, 2002 at 06:07:55PM -0500, Joseph F. Ryan wrote:
> > Secondly, the use of subs to create constants like that is ridiculous.  Try 
> > the constant pragma :)
> > 
> > use constant DEBUGGING                      => 0;
> > use constant EMULATE_MATTS_CODE  => 0;
> > use constant MAILPROG                        => '/usr/lib/sendmail -oi -t';
> 
> I wouldn't say that using it is ridiculous to use subroutines to create
> constants, but this alternative seems reasonable. Is is in the standard
> library of 5.004_04? Does this integrate in strings as easily as a
> normal variable, eg.

use constant works in 5.00404, but it is a little messy to
interpolate it into a string.

> print "Mail program is MAILPROG";

print "Mail program is @{[ MAILPROG ]}";

The big problem (with both constants and subs) is that it makes
the config section of the script look a bit different, and we're
aiming to make it very easy for users with no technical skills to
change from Matt's version to ours by copying their config over.

--
Nick

Re: [Nms-cgi-devel] Open question on variable/constants

[Olivier D. <dr...@sh...>]

On Mon, Jan 28, 2002 at 06:17:27PM -0800, Wizard wrote:
> In an ideal world, it might. However, there is much more overhead associated
> with creating and calling a subroutine then using a simple scalar. When you
> create a subroutine, Perl needs to create a new namespace, stack, etc., and
> then when called, there is quite a bit of code that needs to be executed in
> order to pass all of the information (even if there isn't any explicitly
> passed) to the subroutine.

Would the "use constant CONSTANTNAME => VALUE" be more efficient? As
efficient as scalars, arrays or hash?

> Although your suggestion would work, I think it's
> a bit of overkill for the sake of saying that it's "better programming
> practice".

Maybe I'm pushing it too far, but I thought the aim of this project was
to provide better quality (in delivering a service, in security and as
a coding model) In my opinion, allowing what should be constants to be
modified isn't a very secure practice. Would you do the same in C?

-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

Re: [Nms-cgi-devel] Open question on variable/constants

[Olivier D. <dr...@sh...>]

On Mon, Jan 28, 2002 at 06:07:55PM -0500, Joseph F. Ryan wrote:
> Secondly, the use of subs to create constants like that is ridiculous.  Try 
> the constant pragma :)
> 
> use constant DEBUGGING                      => 0;
> use constant EMULATE_MATTS_CODE  => 0;
> use constant MAILPROG                        => '/usr/lib/sendmail -oi -t';

I wouldn't say that using it is ridiculous to use subroutines to create
constants, but this alternative seems reasonable. Is is in the standard
library of 5.004_04? Does this integrate in strings as easily as a
normal variable, eg.

print "Mail program is MAILPROG";

? In this case it would make this approach much more appealing I think.

-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

Re: [Nms-cgi-devel] FormMail.cgi CIDR (fwd)

[Nick C. <ni...@cl...>]

On Mon, Jan 28, 2002 at 09:05:20PM +0000, Sam Smith wrote:
> 
> I don't have access to Perl 5.004_004 to test this on.  Can someone
> please do that?

Why not get one ?  I have a bare install of every Perl we aim to
support on my laptop, and it only comes to 93M in total.

# du -sk /usr/local/perl-*
10184	/usr/local/perl-5.00404
11164	/usr/local/perl-5.00405
13028	/usr/local/perl-5.005
13680	/usr/local/perl-500503
21332	/usr/local/perl-560
23528	/usr/local/perl-561

--
Nick

RE: [Nms-cgi-devel] Open question on variable/constants

[Wizard <wi...@ne...>]

> Would it be a better programming practice to use subroutines instead of
> variables as constants?

In an ideal world, it might. However, there is much more overhead associated
with creating and calling a subroutine then using a simple scalar. When you
create a subroutine, Perl needs to create a new namespace, stack, etc., and
then when called, there is quite a bit of code that needs to be executed in
order to pass all of the information (even if there isn't any explicitly
passed) to the subroutine. Although your suggestion would work, I think it's
a bit of overkill for the sake of saying that it's "better programming
practice".

Grant M.

Re: [Nms-cgi-devel] Open question on variable/constants

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

First of all, I don't think that we should change config variables to 
constants.  The original MWS didn't use constants as the config, and I 
don't think we should either.  It provides no further benefit for the 
program, and it could only lead to confusion when a non-perl programmer 
tries to edit the config.

Secondly, the use of subs to create constants like that is ridiculous.  Try 
the constant pragma :)

use constant DEBUGGING                      => 0;
use constant EMULATE_MATTS_CODE  => 0;
use constant MAILPROG                        => '/usr/lib/sendmail -oi -t';

Joseph Ryan


At 05:37 PM 1/28/2002 -0500, Olivier Dragon wrote:
>On Mon, Jan 28, 2002 at 09:39:26PM +0000, Jonathan Stowe wrote:
> > In the first place I really am not going to be the
> > one who goes through the code altering the places where these variables
> > are interpolated into quoted strings, which really would mean assigning
> > their values to new variables rather than some @{[EMULATE_MATTS_CODE()]}
> > hack ... and then there is the documentation and the support issues :)
>
>I've (in a subtle way maybe) proposed myself to do it, in which case the
>"it's a lot of work" argument doesn't really hold for anybody but me
>(unless someone would like to help) and since I'm in favor of the
>change, the argument isn't really *against* anything.
>
>-Oli
>
>--
>+----------------------------------------------+
>| Olivier Dragon        dr...@sh... |
>| Software Engineering II, McMaster University |
>+----------------------------------------------+
>
>_______________________________________________
>Nms-cgi-devel mailing list
>Nms...@li...
>https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel

[Nms-cgi-devel] Project docs

[Olivier D. <dr...@sh...>]

I've collected two documents from Dave's emails that I think should be
added to the docs section. It would be rather useful to have for newbies
(like me) who'd like to join.

See below. Send comments. Fix it. Put it up on SF.

-Oli


-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

Re: [Nms-cgi-devel] Open question on variable/constants

[Olivier D. <dr...@sh...>]

On Mon, Jan 28, 2002 at 09:39:26PM +0000, Jonathan Stowe wrote:
> In the first place I really am not going to be the
> one who goes through the code altering the places where these variables
> are interpolated into quoted strings, which really would mean assigning
> their values to new variables rather than some @{[EMULATE_MATTS_CODE()]}
> hack ... and then there is the documentation and the support issues :)

I've (in a subtle way maybe) proposed myself to do it, in which case the
"it's a lot of work" argument doesn't really hold for anybody but me
(unless someone would like to help) and since I'm in favor of the
change, the argument isn't really *against* anything.

-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

Re: [Nms-cgi-devel] FormMail.cgi CIDR (fwd)

[Sam S. <sa...@us...>]

On Mon, 28 Jan 2002, Jonathan Stowe wrote:
> > The below seems to have got lost in the activity of the last few
> > days (not helped by my opaque comment).
> >
> > It allows 130.88.0.0/16 CIDR style masks in @referers .
> >
>
> It appears to :
>
>   A) only allow those masks

It does only allow the a.b.c.d/e mask, since the raw IP is handled
by the if statement below. It adds to the current functionality,
rather than replacing anything.



>   B) summon $5 out of thin air at some point

Oops. New patch below:



--- FormMail.pl	Tue Jan 22 00:13:43 2002
+++ FormMail-sams.pl	Mon Jan 28 21:29:59 2002
@@ -277,6 +277,19 @@
       if ($referer =~ m|https?://([^/]*)\Q$test_ref\E|i) {
 	$check_referer = 1;
 	last;
+      }
+      elsif ( $secure && $test_ref =~ /(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})\/(\d{1,2})/ ) {
+        my $cidr=$5;
+        my $test_bits= unpack "N", pack "CCCC", $1, $2, $3, $4;
+        my $test_bit_mask= unpack "N", pack "B*", "1" x $cidr . "0" x (32 - $cidr );
+
+        $referer =~ /(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/;
+        my $ip_bits= unpack "N", pack "CCCC", $1, $2, $3, $4;
+
+        if (($test_bits & $test_bit_mask) == ($ip_bits & $test_bit_mask)) {
+          $check_referer = 1;
+                  last;
+        }
       }
       elsif ( $secure && $test_ref =~ /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/ ) {
         if ( $referer =~ m|https?://([^/]+)| ) {




Sam

-- 
   Managing sysadmins is like leading a neighborhood gang of
   neurotic pumas on jet-powered hoverbikes with nasty smack habits and
   opposable thumbs.  -- from www.monkeybagel.com

Re: [Nms-cgi-devel] Open question on variable/constants

[Jonathan S. <gel...@ge...>]

On Mon, 28 Jan 2002, Olivier Dragon wrote:
> I would just like to submit a question to everyone to either answer or
> debate.
>
> Would it be a better programming practice to use subroutines instead of
> variables as constants? (As my knowledge of Perl is relatively limited,
> please let me know if this is not backward compatible to 5.004_04)
>

It would be backwardly compatible as far as the Perl interpreter is
concerned but I have grave doubts as to whether using this idiom is going
to address our aims.  In the first place I really am not going to be the
one who goes through the code altering the places where these variables
are interpolated into quoted strings, which really would mean assigning
their values to new variables rather than some @{[EMULATE_MATTS_CODE()]}
hack ... and then there is the documentation and the support issues :)

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

Re: [Nms-cgi-devel] Open question on variable/constants

[Christopher R. <red...@ma...>]

On Mon, 2002-01-28 at 16:10, Olivier Dragon wrote:
> My main arguments against:
> 1. Most, if not all Perl programs use scalars, arrays and hashes
> variables as constants.
> 2. Might break MWS (although I don't see why if we get the code working
> right with it).
> 3. Extra work (in the case where it's done by me, cannot be argued as
> extra work for others :o)

4. Doesn't interpolate directly.
ie compare:
print "Mail program is $mailprog.\n";
vs.
print "Mail program is ", MAILPROG, ".\n";
or even
print "Mail program is @{[MAILPROG]}.\n";

Re: [Nms-cgi-devel] FormMail.cgi CIDR (fwd)

[Jonathan S. <gel...@ge...>]

On Mon, 28 Jan 2002, Sam Smith wrote:

>
> The below seems to have got lost in the activity of the last few
> days (not helped by my opaque comment).
>
> It allows 130.88.0.0/16 CIDR style masks in @referers .
>

It appears to :

  A) only allow those masks

  B) summon $5 out of thin air at some point


I probably have missed something ....


/J\

> I don't have access to Perl 5.004_004 to test this on.  Can someone
> please do that?
>
> Comments?
>
>
>
> Sam
>

-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

[Nms-cgi-devel] Open question on variable/constants

[Olivier D. <dr...@sh...>]

Hi,

I would just like to submit a question to everyone to either answer or
debate.

Would it be a better programming practice to use subroutines instead of
variables as constants? (As my knowledge of Perl is relatively limited,
please let me know if this is not backward compatible to 5.004_04)

Let me explain why I believe that yes is the right answer. I've been
told several times and read it various times as well that a constants is
simply a function that takes no arguments and only returns a value.
Here's an example taken from formmail:

my $emulate_matts_code = 0;
my $secure = 1;
my $mailprog = '/usr/lib/sendmail -oi -t';
my @referers = qw(dave.org.uk 209.207.222.64 localhost);
my @allow_mail_to = qw(yo...@yo... som...@yo... localhost);

This should be enough to illustrate my example. Now this would be
translated into the following format under the premise:

sub EMULATE_MATTS_CODE	{ 0 }
sub SECURE		{ 1 }
sub MAILPROG		{ '/usr/lib/senmail -oi -t' }
sub REFERERS		{ qw(dave.org.uk 209.207.222.64 localhost) }
sub ALLOW_MAIL_TO	{ qw(yo...@yo... som...@yo... localhost) }

(ps, I might be wrong about the behavior of the last two... but you get
my point, at least I hope. I've been successfully writing programs using
this technique)

My main arguments in favor or this:
1. Subroutine values cannot be modified (these are constants right?)
2. Improved code readability ( &CONSTANT instead of $constant or
$CONSTANT) which really distinguishes between code variables and
constants.
3. Seperate configuration (through constants) and algorithms (that use
variables which makes it easier for newbies or people who wish to learn
Perl).

My main arguments against:
1. Most, if not all Perl programs use scalars, arrays and hashes
variables as constants.
2. Might break MWS (although I don't see why if we get the code working
right with it).
3. Extra work (in the case where it's done by me, cannot be argued as
extra work for others :o)

Whaddyatink?
-Olivier


-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

Re: [Nms-cgi-devel] FormMail.cgi CIDR (fwd)

[Sam S. <sa...@us...>]

The below seems to have got lost in the activity of the last few
days (not helped by my opaque comment).

It allows 130.88.0.0/16 CIDR style masks in @referers .

I don't have access to Perl 5.004_004 to test this on.  Can someone
please do that?

Comments?



Sam
-- 
  Mediocrity: It Takes a Lot Less Time, and Most People Won't Notice the
    Difference Until it's Too Late

---------- Forwarded message ----------
Date: Wed, 23 Jan 2002 22:29:14 +0000 (GMT)
From: Sam Smith <sa...@us...>
To: Jonathan Stowe <gel...@ge...>
Cc: nms...@li...
Subject: Re: [Nms-cgi-devel] FormMail.cgi CIDR

On Tue, 22 Jan 2002, Jonathan Stowe wrote:
> On Tue, 22 Jan 2002, Sam Smith wrote:
> > On Tue, 22 Jan 2002, Jonathan Stowe wrote:
> > > On Tue, 22 Jan 2002, Sam Smith wrote:
> > > > The below patch will allow you to put CIDR IP/bitmasks into @referers
> > > > and have it work for the entirity of 10.10.2.0/24 if that's what you
> > > > want.
> > > >
> > >
> > > Nice idea, however if it has 'issues' with 5.005 I am certain it won't
> > > work on 5.004 either :(   I think we should hold on the patch until we can
> > > test it on all the supported platforms ..
> >
> > It appears to be the %b formatting in the sprintf statements.
> >
> > Is there a 5.004 compatible equivalent?
> >
>
> I think that one used to do something funky with unpack :)

Something like the below?


--- FormMail.pl	Tue Jan 22 00:13:43 2002
+++ FormMail-sams.pl	Wed Jan 23 22:26:21 2002
@@ -277,6 +277,19 @@
       if ($referer =~ m|https?://([^/]*)\Q$test_ref\E|i) {
 	$check_referer = 1;
 	last;
+      }
+      elsif ( $secure && $test_ref =~ /(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})\/\d{1,2}/ ) {
+        my $cidr=$5;
+        my $test_bits= unpack "N", pack "CCCC", $1, $2, $3, $4;
+        my $test_bit_mask= unpack "N", pack "B*", "1" x $cidr . "0" x (32 - $cidr );
+
+        $referer =~ /(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/;
+        my $ip_bits= unpack "N", pack "CCCC", $1, $2, $3, $4;
+
+        if (($test_bits & $test_bit_mask) == ($ip_bits & $test_bit_mask)) {
+          $check_referer = 1;
+                  last;
+        }
       }
       elsif ( $secure && $test_ref =~ /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/ ) {
         if ( $referer =~ m|https?://([^/]+)| ) {

Re: [Nms-cgi-devel] New Subscribers

[Jonathan S. <gel...@ge...>]

On Mon, 28 Jan 2002, Dave Cross wrote:
>
> I thought it was worthwhile at this point reiterating some of the rules of
> nms so you know what you're getting into.
>

...


* And I am a complete and utter bastard when it comes to obfuscation and
tabbed indents :)

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

Re: [Nms-cgi-devel] New Subscribers

[Jonathan S. <gel...@ge...>]

On Mon, 28 Jan 2002, Jonathan Stowe wrote:
> On Mon, 28 Jan 2002, Dave Cross wrote:
> >
> > * If you want to enhance or extend Matt's original functionality, then please
> >   use a variable called $EMULATE_MATTS_CODE. If this variable is set to a
> >   true value then your new functinoality should be switched off.
> >
>
> I have noticed on a quick scan of the code that we seem to have this
> variable in both upper case and lower case ... someone might want to fix
> this ( OK, I'll do it tonight and fix it at the upper case ).
>

Ignore that. I have fixed countdown so it uses lower case :)

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

Re: [Nms-cgi-devel] New Subscribers

[Jonathan S. <gel...@ge...>]

On Mon, 28 Jan 2002, Dave Cross wrote:
>
> * If you want to enhance or extend Matt's original functionality, then please
>   use a variable called $EMULATE_MATTS_CODE. If this variable is set to a
>   true value then your new functinoality should be switched off.
>

I have noticed on a quick scan of the code that we seem to have this
variable in both upper case and lower case ... someone might want to fix
this ( OK, I'll do it tonight and fix it at the upper case ).

/J\
-- 
Jonathan Stowe                      |
<http://www.gellyfish.com>          |      This space for rent
                                    |

Re: [Nms-cgi-devel] New Subscribers

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

On Sun, Jan 27, 2002 at 10:24:21PM +0000, Dave Cross (da...@da...) wrote:
> I see that the number of subscribers on this list has grown substantially
> on this list since the perl.com article was published. There are now 33 of
> us. The number of registered nms developers, however, has remained constant
> at 6.
> 
> I thought it might therefore be useful to remind you all that we're pretty
> inclusive on this project. Anyone can become a developer. All you need to do
> is to register with SourceForge at 
> 
> <https://sourceforge.net/account/register.php>
> 
> and then drop me an email with your new SourceForge username. I'll then add
> you to the list of nms developers and you'll then be able to contribute
> directly by accessing the code in our CVS repository.

Well that certainly did the trick. We now have 12 developers. Welcome 
everyone.

I thought it was worthwhile at this point reiterating some of the rules of
nms so you know what you're getting into.

* All code must run under Perl 5.004_04.

* Only modules included with Perl 5.004_04 should be used.

* All code should run under "use strict" and "-wT" without errors.

* If you want to enhance or extend Matt's original functionality, then please
  use a variable called $EMULATE_MATTS_CODE. If this variable is set to a
  true value then your new functinoality should be switched off.

* Please keep the docs up to date.

If you have any ideas of new work that you'd like to do on any of the scripts
then please announce it here first. After announcing it, please wait at 
least 24 hurs before starting. If, after 24 hours, no-one has objected to
your suggestions then please go ahead. As a corollary to that, if you see 
someone suggesting something here that you don't agree with, then please
speak up.

That's all for now. Thanks for getting involved.

Dave...

-- 

  .sig missing...

[Nms-cgi-devel] Greetings!

[Olivier D. <dr...@sh...>]

Hi to everyone,

I'm new here and I'd like to help with the documentation. My name is
Olivier Dragon and I'm from Quebec (currently in Ontario), Canada. I'm
currently studying Software Engineering at McMaster University.

I've been using Perl for about a year now and I've become familiar with
it. I'm no expert, but I can read and write the code :o)

I've just checked out the source for search and formmail. My goal is to
make the code easier to understand by inserting various comments. I
would also like to ease the configuration which doesn't seem very clear
to me at a first look and probably doesn't for a newbie who doesn't know
Perl. Also I think it would probably be a good idea to put the changelog
in a seperate file.

Is anybody working on this? Are there any rules I should know before I
get started on anything? Is there anything outlined above that I
shouldn't do?

Thanks,
-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+

[Nms-cgi-devel] Cookielib example file

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

We still need example .html/.pl files for the cookielib.  The NMS Cookie 
lib was tested with Matt Wright's example files, but we can't use them or 
else Matt will get out his lawyer stick and beat us over the head with 
it.  So, we need to make new ones.  I think they should be pretty similar 
in function to the ones that he had, but rewritten with strict and -w.

I can do it, but I won't have a chance till tuesday.  If anyone can do it 
beforehand, by all means go ahead.

Joseph Ryan

[Nms-cgi-devel] Re: FAQ file not found

[Lucy M. <le...@he...>]

Dave Cross wrote:
> Alex BATKO (ab...@mi...) wrote:

> > | > http://sourceforge.net/docman/display_doc.php?docid=7962&group_id=39625
> > | >
> > | Or the alternative URL is <http://nms-cgi.sourceforge.net/FAQ.html>
> > +-------------------
> This is very strange. No matter what I do, I can't get it to fail. Has
> anyone else tried?

Both work for me.  Sorry about one-liner ;-)


L.
cam.pm.org