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

[Nms-cgi-devel] [ nms-cgi-Support Requests-717077 ] script error

[SourceForge.net <no...@so...>]

Support Requests item #717077, was opened at 2003-04-07 15:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=717077&group_id=39625

Category: Install Problem (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: script error

Initial Comment:
I get the following error upon submission to the 
nms.guestbook script:

CGI Error
The specified CGI application misbehaved by not 
returning a complete set of HTTP headers. The 
headers it did return are:
Too late for "-T" option at d:\64.225.58.142\cgi-
bin\guestbook.pl line 1.

Any suggestions?

Thank you,
Jacki Barber
ja...@ne... 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=425770&aid=717077&group_id=39625

[Nms-cgi-devel] Re: Re: I have a cgi app for your project

[<ric...@be...>]

> 
> From: Dave Cross <da...@da...>
> Date: 2003/04/05 Sat AM 10:12:33 EST
> To: ric...@be...
> CC: nms...@li...
> Subject: Re: I have a cgi app for your project
> 
> On Thu, Mar 27, 2003 at 11:27:31AM -0800, Richie Wood (ric...@us...) wrote:
> > It creates a bread crumb on an html document so users can navigate
> > directories easier. Only works using ssi though, kinda like a text
> > counter. Its an extremely small script. Just something I wrote while
> > trying to teach myself Perl. It is clean however. Email me at
> > ric...@be... and I'll attach it and reply back. I'm
> > relatively new to sourceforge and couldn't figure out a way to attach
> > it to this message.
> 
> Richie,
> 
> Sounds interesting. If you reply to this email, it should go to the
> nms developers list at nms...@li.... If you
> attach your program they will take a look at it.
> 
> Dave...
> 
> -- 
>   Two slightly distorted guitars
> 

Here you go. Keep in mind I'm still learning Perl I come from a C background so I might have done alot of stuff wrong or un-perl way. I'm really enjoying learning perl. If there are any tips or things I did wrong please let me know. I gpl'd the script so do with it as you please. Thanks

[Nms-cgi-devel] Fwd: [shaz@chewedkandi.net: ]

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

Isn't it nice to know we're appreciated.

Dave...

----- Forwarded message from Sharon Milne <sh...@ch...> -----

From: "Sharon Milne" <sh...@ch...>
To: <da...@us...>

Hi!

I just want to e-mail you guys and say thank you!

I have used your form mailer script and found it easy to configure with the
instructions supplied.

I am a first time user of cgi's and looked all over for a cgi script to use
to send mail from my site and I came across your site and scripts. I found
them very easy to use!

I am just writing to say thank you and keep up the good work :)

Shaz


----- End forwarded message -----

-- 
  Drugs are just bad m'kay

[Nms-cgi-devel] Re: I have a cgi app for your project

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

On Thu, Mar 27, 2003 at 11:27:31AM -0800, Richie Wood (ric...@us...) wrote:
> It creates a bread crumb on an html document so users can navigate
> directories easier. Only works using ssi though, kinda like a text
> counter. Its an extremely small script. Just something I wrote while
> trying to teach myself Perl. It is clean however. Email me at
> ric...@be... and I'll attach it and reply back. I'm
> relatively new to sourceforge and couldn't figure out a way to attach
> it to this message.

Richie,

Sounds interesting. If you reply to this email, it should go to the
nms developers list at nms...@li.... If you
attach your program they will take a look at it.

Dave...

-- 
  Two slightly distorted guitars

Re: [Nms-cgi-devel] Re: FormMail.pl

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

On Tue, Mar 25, 2003 at 10:48:04PM +0000, Dave Cross wrote:
> On Mon, Feb 24, 2003 at 08:43:38AM -0500, Howard L. Funk (co...@hl...) wrote:
> > Hallo Dave,
> > 
> > I am delighted with the FormMail.pl script. I would like to suggest a small 
> > enhancement. As presently configured, when an invalid email address (but in 
> > the correct format) is specified, many mail servers will bounce the message 
> > to the ISP. The use of the -f flag in the invocation of SENDMAIL as
> > 	-f $error
> > 
> > where $error is defined in the variables list as the address to which 
> > bounces should be sent can overcome this problem.
> 
> Thanks for the email. I've forwarded it to the nms developers.

That feature is already there, but the variable is called $postmaster
rather than $error.

--
Nick

[Nms-cgi-devel] Re: FormMail.pl

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

On Mon, Feb 24, 2003 at 08:43:38AM -0500, Howard L. Funk (co...@hl...) wrote:
> Hallo Dave,
> 
> I am delighted with the FormMail.pl script. I would like to suggest a small 
> enhancement. As presently configured, when an invalid email address (but in 
> the correct format) is specified, many mail servers will bounce the message 
> to the ISP. The use of the -f flag in the invocation of SENDMAIL as
> 	-f $error
> 
> where $error is defined in the variables list as the address to which 
> bounces should be sent can overcome this problem.

Thanks for the email. I've forwarded it to the nms developers.

Dave...

-- 
  It was long ago and it was far away
  And it was so much better that it is today

[Nms-cgi-devel] Re: [Nms-cgi-support] Guestbook script

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

On Mon, Mar 31, 2003 at 12:22:39AM -0800, Clive Walker (cli...@cv...) wrote:
> Below is the result of your feedback form.  It was submitted by
> Clive Walker (cli...@cv...) on Monday, March 31, 2003 at 08:22:33
> ---------------------------------------------------------------------------
> 
> description: Great guestbook script - thanks. Unfortunately our
> website guestbook has been abused by people adding spam comments (a
> guestbook risk) so I disabled it by removing the html page
> addguest.html. However, some comments were added after this.
> Presumably by accessing the guestbook.pl script in some way ? I am no
> Perl expert and I am not sure how this was done. I have now removed
> the pl script as well which I hope will stop people ading spam.
> Anyway, the reason for the comment is to ask that the next version of
> the guestbook script has an option that will allow the administrator
> to approve comments before publishing ? Thanks - Clive Walker

Thanks for the suggestion. I've forwarded it to our developers.

Dave...

-- 
  Two slightly distorted guitars

[Nms-cgi-devel] Matt Wright purchases CPAN

[Paul R. <pa...@ro...>]

So, I assume everyone has seen today's cpan.org homepage:

    http://www.cpan.org/

and the accompanying use Perl story:

    http://use.perl.org/article.pl?sid=03/04/01/1224229

    " The continued popularity of Matts scripts inspite of NMS attempts to 
    undermine it is touted by some as proof that all the fuss is just too 
    many $`$'$&s in the s//g. "

-paul

[Nms-cgi-devel] Secure asp formmail

[Jennifer <tox...@ma...>]

Just wondering if anyone has a suggestion of a secure asp formmail.  I 
tried to install nms formmail on a windows server and I tried using SMTP 
and also mail.exe, but the host said that the only options are Jmail or 
ASPmail. Unless I am missing something I don't how I can use these with the 
perl script. I have found many existing formmail asp scripts that use Jmail 
or such, but they've been ported from Matt's and exhibit all the same 
security problems.

I really wish the client would just use a Unix server, but failing that and 
if I can't find an existing one, I will have to write one from scratch 
which I really didn't want to have to do.

I did notice the sample script the host set up works and uses localhost as 
the SMTP. I did try setting $mailprog to SMTP:localhost It didn't generate 
and error, but I never got an email from it.  Is there a way to make that work?

Jennifer 

[Nms-cgi-devel] Some little suggestions for FormMail

[Jennifer <tox...@ma...>]

Just a couple of little things.

$postmaster, $no_content, $double_spacing, $wrap_text, $wrap_style are 
included in the README but are not an items in the POD documentation in 
FormMail.pl itself.

Since many people change the name of the script, use $ENV{'SCRIPT_NAME'} in 
place of /cgi-bin/FormMail.pl in the request method error message.

Make the bgcolor for the error table, tr, td configurable. Either give them 
a css class or make them a variable. My preference would be to center that 
table too. :-)

Also, shouldn't the copyright notice on the error page be updated to 
include the current year (2001-2003)?

Like I said, little things, but maybe they can be added to the next release.

Jennifer
P.S. Sorry for the test message. I thought I had unsubscribed and when I 
went to subscribe again it said I already was, but I hadn't seen any posts 
recently.

[Nms-cgi-devel] TEST IGNORE

[Jennifer <tox...@ma...>]

[Nms-cgi-devel] Re: with reference to last email I sent.

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

Thanks. Forwarded that to the developers too.

Dave...

On Sun, Feb 16, 2003 at 04:41:27PM +0000, Ricky Chan (ric...@br...) wrote:
> A revised patch..
> 
> Took the unpack out of loop as that would have broken after the first test.
> 
> Ricky
> 
> --- FormMail.pl.orig    Mon Jan 27 21:02:01 2003
> +++ FormMail.pl Sun Feb 16 16:36:29 2003
> @@ -242,4 +242,8 @@
> 
>      $refHost = $2;
> +    my $ref_host = inet_aton($refHost);
> +    if( $ref_host) {
> +      $ref_host = unpack "l", $ref_host;
> +    }
> 
>      foreach my $test_ref (@referers) {
> @@ -249,6 +253,5 @@
>        }
>        elsif ( $secure && $test_ref =~ 
> /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/ ) {
> -        if ( my $ref_host = inet_aton($refHost) ) {
> -          $ref_host = unpack "l", $ref_host;
> +        if ( $ref_host ) {
>            if ( my $test_ref_ip = inet_aton($test_ref) ) {
>              $test_ref_ip = unpack "l", $test_ref_ip;
> 

-- 
  It was long ago and it was far away
  And it was so much better that it is today

[Nms-cgi-devel] Re: bug/quirk of FormMail - patch included

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

Ricky,

Thanks for the patch. I've forwarded it to the developers list for
discussion.

Dave...

On Thu, Feb 13, 2003 at 12:28:49PM +0000, Ricky Chan (ric...@br...) wrote:
> I work for an ISP and installed your scripts to replace matts scripts.
> 
> The bug is related to DNS entry with more than 1 A record.
> 
> It works perfectly if you use the website name in referers array. (e.g.
> qw(www.users.globalnet.co.uk)
> 
> BUT when you use the actual A records
> qw(80.189.94.31 80.189.92.31)
> 
> You get occasional failures.. I did some tests and noticed:
> 
> 80.189.92.31,526302544 ne www.users.globalnet.co.uk,526171472
> 80.189.94.31,526171472 ne www.users.globalnet.co.uk,526302544
> 
> As you see it depends on what inet_aton gets back from a A record for 
> the website.
> 
> The more A records the more likely hood of not matching and failing.
> 
> The patch I submit, moves the inet_aton for the refHost outside the loop 
> so does NOT change every iteration.  Probs has a small (insignificant) 
> speed gain as well.
> 
> Apart from the script works a charm and I threw away the old matt 
> formmail and did need me to write my own.
> 
> 
> Ricky

> --- FormMail.pl Thu Feb 13 12:20:07 2003
> +++ FormMail.pl.orig    Thu Feb 13 12:19:34 2003
> @@ -240,17 +240,16 @@
>    if ($referer && ($referer =~ m!^https?://([^/]*\@)?([\w\-\.]+)!i)) {
>      my $refHost;
> 
>      $refHost = $2;
> -    my $ref_host = inet_aton($refHost);
> 
>      foreach my $test_ref (@referers) {
>        if ($refHost =~ m|\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}/ ) {
> -        if ( $ref_host ) {
> +        if ( my $ref_host = inet_aton($refHost) ) {
>            $ref_host = unpack "l", $ref_host;
>            if ( my $test_ref_ip = inet_aton($test_ref) ) {
>              $test_ref_ip = unpack "l", $test_ref_ip;
>              if ( $test_ref_ip == $ref_host ) {
> 


-- 
  .sig missing...

Re: [Nms-cgi-devel] Re: [Nms-cgi-support] RE: Formmail.pl help

[Simon W. <es...@ou...>]

On Wed, 26 Feb 2003, Nick Cleaton wrote:

> Can anyone see any reason not to add
> 
> Sender: $postmaster
> 
> to the FormMail message headers to keep MTAs like this happy when
> there's no valid From field ?

Some MUA's will prefer the Sender header over the From header, I think 
Lotus Notes is one such, which can mess up replies.

So it might be better to add it as a configurable option, disabled by 
default.

Simon.

[Nms-cgi-devel] Re: [Nms-cgi-support] RE: Formmail.pl help

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

On Tue, Feb 25, 2003 at 04:36:43PM -0500, Brian Mullins wrote:
>
> Woohoo!!!  The 'Sender: $postmaster' command worked... as you can see above.
> Thanks for all of your help with getting this to work.
> 

Can anyone see any reason not to add

Sender: $postmaster

to the FormMail message headers to keep MTAs like this happy when
there's no valid From field ?

--
Nick

RE: processing configuration (was) RE: Organisation filteringRE:[Nms-cgi-devel] Anyone...Anyone...?

[Simon W. <es...@ou...>]

On Wed, 2003-02-19 at 14:51, Wizard wrote:
> > As always though, this is my opinion and it's your project !
> 
> It's not my project, it belongs to everyone.

OK, what I meant was that you're the one doing the coding, as a
volunteer. You're not a code-monkey employed to bash out somebody else's
design !

As far as I'm concerned, you're entitled to code things however you feel
happiest with, on the basis that you're the one who's stepped up to do
it, not me.

It's your decision what goes in. That's what I was trying to say :)

Simon.

RE: processing configuration (was) RE: Organisation filteringRE:[Nms-cgi-devel] Anyone...Anyone...?

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

> Conversely, I can't tell you the number of times that I've had to chase
> through duplicated code because one splits on ", " and one on /,\s+/.
>
> Putting the code in modules allows us to write tests so that we know
> that it returns what it is supposed to.
>
> One of our objectives is to show best practice in perl programming so I
> think it would be wise to ensure we have no code duplication and proper
> tests.

As per your statement above I will create a get_array instead of using
caller context, so that we truly do 'know that it returns what it is
supposed to'.


> As always though, this is my opinion and it's your project !

It's not my project, it belongs to everyone. My dissent is not because I'm
opposed to input, but simply because I don't agree with your argument.
That's what makes better software. If you don't convince me it doesn't mean
I won't do it. However if it becomes a problem support-wise, it will likely
be too late to remove it.

Grant M.

RE: processing configuration (was) RE: Organisation filtering RE:[Nms-cgi-devel] Anyone...Anyone...?

[Simon W. <es...@ou...>]

On Wed, 2003-02-19 at 14:12, Wizard wrote:
> >
> > Me too.  Splitting a string into a list of values has nothing to do
> > with the fact that the string came from a file.
> 
> I must admit I'm more concerned that this is something likely to break, and
> when it does, you have to go searching from module to module to module to
> see what's going on. That I don't like. If it's staring you right in the
> face at first glance, you'll know where you broke it.
> 
> I'll add caller context to get() (wantarray), but I REALLY don't like using
> it for this application. I think it confuses problem resolution for an
> aspect that I see as potentially problematic in the first place. I'll put it
> in, but I definitely don't think it's a good idea. I can't tell you how many
> times I've had to chase errors through hierarchies of modules, only to find
> it was something simple.

Conversely, I can't tell you the number of times that I've had to chase
through duplicated code because one splits on ", " and one on /,\s+/.

Putting the code in modules allows us to write tests so that we know
that it returns what it is supposed to.

One of our objectives is to show best practice in perl programming so I
think it would be wise to ensure we have no code duplication and proper
tests.

As always though, this is my opinion and it's your project !

Simon.

RE: processing configuration (was) RE: Organisation filtering RE:[Nms-cgi-devel] Anyone...Anyone...?

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

Sorry I took so long to get back. I was pretty tired after 6+ hours of
shoveling, so I didn't get back to this.

> > I see. I would like to see a get_array method. I admit that this
> > separation of concerns is a bit of a thing with me. I just don't like to
> > see processing of variables in otherwise unrelated code. It just makes
> > life difficult when you want to change something, remembering all the
> > places where you split the scalar.
>
> Me too.  Splitting a string into a list of values has nothing to do
> with the fact that the string came from a file.

I must admit I'm more concerned that this is something likely to break, and
when it does, you have to go searching from module to module to module to
see what's going on. That I don't like. If it's staring you right in the
face at first glance, you'll know where you broke it.

I'll add caller context to get() (wantarray), but I REALLY don't like using
it for this application. I think it confuses problem resolution for an
aspect that I see as potentially problematic in the first place. I'll put it
in, but I definitely don't think it's a good idea. I can't tell you how many
times I've had to chase errors through hierarchies of modules, only to find
it was something simple.

> IMO we should be looking to end up somewhere like:
>
> CGI::NMS::Config
>
>   Defines the get(), is_true() and get_list() methods.  Provides
>   default implementations for is_true() and get_list(), implemented
>   in terms of get().
>
> CGI::NMS::Config::File
>
>   Inherits from CGI::NMS::Config
>
>   Implements new() to read in and parse the file, and get() to
>   fetch a value.

We discussed something like this earlier, and I'll try to get to it at some
point, but not this first alpha (This sounds different from what we
originally discussed). I really do need to finish something. I'll add the
context calling, for now. Perhaps before we release this or in the next
version I can go through all of the issues that we've talked about and do
clean-up.

Grant M.

Re: processing configuration (was) RE: Organisation filtering RE:[Nms-cgi-devel] Anyone...Anyone...?

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

On Tue, Feb 18, 2003 at 01:07:27PM +0000, Simon Wilcox wrote:
> > 
> > Right now, the interface only requires the following methods:
> > $scalar = $cfg->get( 'key' );
> > $bool = $cfg->is_true( 'key' );
> > $bool = $cfg->is_false( 'key' );
> > 
> > If it's desired, we could add get_array and/or get_hash to the interface,
> > but I really don't think that's necessary considering how simple it is to
> > get a comma separated list into an array. I'm also not sure that it could be
> > done safely without making the configuration file format more complex for
> > the user, either.
> 
> I see. I would like to see a get_array method. I admit that this
> separation of concerns is a bit of a thing with me. I just don't like to
> see processing of variables in otherwise unrelated code. It just makes
> life difficult when you want to change something, remembering all the
> places where you split the scalar.

Me too.  Splitting a string into a list of values has nothing to do
with the fact that the string came from a file.

IMO we should be looking to end up somewhere like:

CGI::NMS::Config

  Defines the get(), is_true() and get_list() methods.  Provides
  default implementations for is_true() and get_list(), implemented
  in terms of get().

CGI::NMS::Config::File

  Inherits from CGI::NMS::Config

  Implements new() to read in and parse the file, and get() to
  fetch a value.

--
Nick

Re: processing configuration (was) RE: Organisation filtering RE:[Nms-cgi-devel] Anyone...Anyone...?

[Nicholas C. <ni...@cc...>]

On Tue, Feb 18, 2003 at 07:25:01AM -0500, Wizard wrote:

> The config module doesn't know what it will be processing, and it doesn't
> want to. Down the road, it may be running under NMSBoard, NMSCount,
> NMSuperDuper, NMSWhatchamacallit, etc. We don't want to add that level of
> specialization to management of one script's configuration variables.

NMSBrainSurgeonExpertSystem

  "Hi, Dr Nic"
  "Hi everybody"

(or more likely
  "My brain hurts" ...
)

Nicholas Clark

RE: processing configuration (was) RE: Organisation filtering RE:[Nms-cgi-devel] Anyone...Anyone...?

[Simon W. <es...@ou...>]

On Tue, 2003-02-18 at 12:25, Wizard wrote:
> 
> > If you know you're going to be processing a list, it makes sense to
> > process the list when you read the config file. Then, if you want to use
> > that list in a second place, you don't have to duplicate the code to
> > turn a scalar into a list.
> 
> The config module doesn't know what it will be processing, and it doesn't
> want to. Down the road, it may be running under NMSBoard, NMSCount,
> NMSuperDuper, NMSWhatchamacallit, etc. We don't want to add that level of
> specialization to management of one script's configuration variables.

Ah yes. Good point.

> > If we plan to abstract it, then we really want to make sure that the
> > code gets what it expects now, and not do further processing in the main
> > code.
> 
> Right now, the interface only requires the following methods:
> $scalar = $cfg->get( 'key' );
> $bool = $cfg->is_true( 'key' );
> $bool = $cfg->is_false( 'key' );
> 
> If it's desired, we could add get_array and/or get_hash to the interface,
> but I really don't think that's necessary considering how simple it is to
> get a comma separated list into an array. I'm also not sure that it could be
> done safely without making the configuration file format more complex for
> the user, either.

I see. I would like to see a get_array method. I admit that this
separation of concerns is a bit of a thing with me. I just don't like to
see processing of variables in otherwise unrelated code. It just makes
life difficult when you want to change something, remembering all the
places where you split the scalar.

Doing it in one place would be handy but not, I guess, essential.

> > OK, so these will always be scalars. My suggestion still stands but I'll
> > wait until I see code to comment further.
> 
> That's fine, it should be up soon. I have to go back to shoveling my 22
> inches of snow now ;-).

Coo. Snow. I like snow. But then I don't have 22" of it to shovel :)

Enjoy.

Simon.

RE: processing configuration (was) RE: Organisation filtering RE:[Nms-cgi-devel] Anyone...Anyone...?

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

> If you know you're going to be processing a list, it makes sense to
> process the list when you read the config file. Then, if you want to use
> that list in a second place, you don't have to duplicate the code to
> turn a scalar into a list.

The config module doesn't know what it will be processing, and it doesn't
want to. Down the road, it may be running under NMSBoard, NMSCount,
NMSuperDuper, NMSWhatchamacallit, etc. We don't want to add that level of
specialization to management of one script's configuration variables.

> If we plan to abstract it, then we really want to make sure that the
> code gets what it expects now, and not do further processing in the main
> code.

Right now, the interface only requires the following methods:
$scalar = $cfg->get( 'key' );
$bool = $cfg->is_true( 'key' );
$bool = $cfg->is_false( 'key' );

If it's desired, we could add get_array and/or get_hash to the interface,
but I really don't think that's necessary considering how simple it is to
get a comma separated list into an array. I'm also not sure that it could be
done safely without making the configuration file format more complex for
the user, either.

> OK, so these will always be scalars. My suggestion still stands but I'll
> wait until I see code to comment further.

That's fine, it should be up soon. I have to go back to shoveling my 22
inches of snow now ;-).
Grant M.

RE: processing configuration (was) RE: Organisation filtering RE: [Nms-cgi-devel] Anyone...Anyone...?

[Simon W. <es...@ou...>]

On Tue, 2003-02-18 at 11:19, Wizard wrote:
> > OK, that seems to do much the same thing. It just seemed to make sense to
> > do all the config variable procesing in one place but...
> 
> It's not that your idea doesn't make sense, it's just that it is really not
> do-able. We discussed the configuration system earlier, and thought that it
> might be abstracted at some point, so we're keeping it as simple as
> possible.

If you know you're going to be processing a list, it makes sense to
process the list when you read the config file. Then, if you want to use
that list in a second place, you don't have to duplicate the code to
turn a scalar into a list.

If we plan to abstract it, then we really want to make sure that the
code gets what it expects now, and not do further processing in the main
code.

> > ...I'll wait to see the finished code. I'm curious about these user
> > defined variables and how they will be used. I'll wait to read the
> > code/docs and comment further then.
> 
> They're mostly just used as replacement strings for the templates. For
> instance {=NMS_USER_CFG_my_advert=} in the template will take the
> configuration directive:
> USER_CFG_my_advert = <a href="http://mywebsite">Go to my website</a>
> and replace the tag with it. No processing for safety, mind you, just read
> and replace. At some point I may add language-accept & browser ID tags,
> though. It's not in yet, so if you have any objections...

OK, so these will always be scalars. My suggestion still stands but I'll
wait until I see code to comment further.

Simon.

RE: processing configuration (was) RE: Organisation filtering RE: [Nms-cgi-devel] Anyone...Anyone...?

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

> OK, that seems to do much the same thing. It just seemed to make sense to
> do all the config variable procesing in one place but...

It's not that your idea doesn't make sense, it's just that it is really not
do-able. We discussed the configuration system earlier, and thought that it
might be abstracted at some point, so we're keeping it as simple as
possible.

> ...I'll wait to see the finished code. I'm curious about these user
> defined variables and how they will be used. I'll wait to read the
> code/docs and comment further then.

They're mostly just used as replacement strings for the templates. For
instance {=NMS_USER_CFG_my_advert=} in the template will take the
configuration directive:
USER_CFG_my_advert = <a href="http://mywebsite">Go to my website</a>
and replace the tag with it. No processing for safety, mind you, just read
and replace. At some point I may add language-accept & browser ID tags,
though. It's not in yet, so if you have any objections...

Grant M.