Menu
▾
▴
nms-cgi-devel — Developers discussion for NMS CGI programs
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(90) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(183) |
Feb
(124) |
Mar
(123) |
Apr
(75) |
May
(49) |
Jun
(60) |
Jul
(58) |
Aug
(41) |
Sep
(27) |
Oct
(30) |
Nov
(13) |
Dec
(19) |
| 2003 |
Jan
(119) |
Feb
(70) |
Mar
(5) |
Apr
(16) |
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(4) |
Dec
(7) |
| 2004 |
Jan
(9) |
Feb
|
Mar
(1) |
Apr
(7) |
May
(12) |
Jun
(4) |
Jul
(11) |
Aug
(17) |
Sep
(3) |
Oct
(15) |
Nov
(7) |
Dec
(2) |
| 2005 |
Jan
(4) |
Feb
(7) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
(9) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2006 |
Jan
(5) |
Feb
(7) |
Mar
(19) |
Apr
(8) |
May
(6) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2007 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: iain t. <ic...@eh...> - 2002-02-02 12:40:18
|
* Wizard (wi...@ne...) [02 Feb 2002 23:30]: > > I was just wondering if people has figured out how to have cvs put > > the log in a different file, or if anything has been tried. > There's a CVS admin file called 'loginfo', which I believe does what > you are expecting. It's purpose is to run a program at every commit. > I've never used it, so you're on your own. Here's an excerpt from the > man: Personally, I think a 'project build' script. i.e. one runs the script and it 'cvs export's the project files and does a 'cvs log' of the project as well and pipes that to a file in the project dir (but not a cvs'd file). Ideally, it would then tar.gz and zip the dir and upload them to the sourceforge pages. This way, if we wanted to release a new version it would merely involve someone running the script. Similar with the FAQ and so on. Should just be scripted. Of course, the FAQ's script could be put into the CVS to be automatically run on commits. It's possibly an XP tenet, but it's definitely a generic good practice tenet: make everything automated. It reduces the chance of errors and removes the tedium of making releases. Comments? Volunteers? -- iain. <http://eh.org/~koschei/> |
|
From: Wizard <wi...@ne...> - 2002-02-02 12:12:21
|
> I was just wondering if people has figured out how to have cvs put the > log in a different file, or if anything has been tried. There's a CVS admin file called 'loginfo', which I believe does what you are expecting. It's purpose is to run a program at every commit. I've never used it, so you're on your own. Here's an excerpt from the man: (http://www.cvshome.org/docs/manual/cvs_18.html#SEC169) ==== Excerpt ========================================= The following `loginfo' file, together with the tiny shell-script below, appends all log messages to the file `$CVSROOT/CVSROOT/commitlog', and any commits to the administrative files (inside the `CVSROOT' directory) are also logged in `/usr/adm/cvsroot-log'. Commits to the `prog1' directory are mailed to ceder. ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER ^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log ^prog1 Mail -s %s ceder The shell-script `/usr/local/bin/cvs-log' looks like this: #!/bin/sh (echo "------------------------------------------------------"; echo -n $2" "; date; echo; cat) >> $1 Grant M. |
|
From: Jonathan S. <gel...@ge...> - 2002-02-02 10:19:24
|
On Fri, 1 Feb 2002, Joseph F. Ryan wrote: > At 10:54 PM 2/1/2002 +0000, Nick wrote: > > > >I think I fixed it a bit, there were some odds and ends from the > >old chdir taint botch still lying around. > > > >If detaint_dirname is killing the script it should be telling you > >the name of the directory it doesn't like. > > It was returning an empty string... > also, should the script die if it hits a bad filename, or just skip it? > I think Nick and myself are of the same opinion with respect to having the program die if the detainting conditions aren't met - I think it should be the responsibility of the caller to make this non-fatal (using eval) if this is desireable. /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Jonathan S. <gel...@ge...> - 2002-02-02 10:13:24
|
On Fri, 1 Feb 2002, Olivier Dragon wrote: > > I was just wondering if people has figured out how to have cvs put the > log in a different file, or if anything has been tried. > I would guess that nothing has been tried because, unless I have missed something fundamental about CVS (and I don't think so), anything that happens automatically to the file happens on the server side and can't create or update local files apart from those that are being updated in the repository. Personally as a *developer* I would prefer to have the change logs in the files that are being edited, and as a *manager of developers* (in the real world) I would like it that the change logs are present in the files while they are being actively developed. This is so that a programmer, on opening a file for editing, will see (hopefully) what the last committed action on that file was - this may prevent reduplication of work or breakage due to cross purposes, it may help in the diagnosis when something that is being added to the code doesnt work as expected. I don't know about anyone else but I don't always find it easy reading other peoples code and seeing the changes in code almost impossible. Now this possibly at variance with the other aims of the project, so I would suggest that we keep the Log entries in the file and have them removed to a Changes file when a release - the average punters shouldn't be using the CVS versions as they are probably broken and almost certainly incomplete ... /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Joseph F. R. <rya...@os...> - 2002-02-01 23:38:58
|
At 10:54 PM 2/1/2002 +0000, you wrote:
>On Thu, Jan 31, 2002 at 11:07:27PM -0500, Joseph F. Ryan wrote:
> > I was fixing a typo in the simple search config description when I decided
> > to give it a try. It didn't work. Detaint_dirname killed the script
> > (there were no directory names which should have killed it), and I
> couldn't
> > get the recursion to work with ('*.html, */*.html, */*/*.html,
> > */*/*/*.html). Did we decide on another method? Perhaps we should have
> > recursion on by default if $Emulate_Matts_Code is set to 0, and keep the
> > old method if it is set to 1.
>
>I think I fixed it a bit, there were some odds and ends from the
>old chdir taint botch still lying around.
>
>If detaint_dirname is killing the script it should be telling you
>the name of the directory it doesn't like.
It was returning an empty string...
also, should the script die if it hits a bad filename, or just skip it?
>--
>Nick
>
>_______________________________________________
>Nms-cgi-devel mailing list
>Nms...@li...
>https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel
|
|
From: Nick C. <ni...@cl...> - 2002-02-01 22:55:18
|
On Thu, Jan 31, 2002 at 11:07:27PM -0500, Joseph F. Ryan wrote:
> I was fixing a typo in the simple search config description when I decided
> to give it a try. It didn't work. Detaint_dirname killed the script
> (there were no directory names which should have killed it), and I couldn't
> get the recursion to work with ('*.html, */*.html, */*/*.html,
> */*/*/*.html). Did we decide on another method? Perhaps we should have
> recursion on by default if $Emulate_Matts_Code is set to 0, and keep the
> old method if it is set to 1.
I think I fixed it a bit, there were some odds and ends from the
old chdir taint botch still lying around.
If detaint_dirname is killing the script it should be telling you
the name of the directory it doesn't like.
--
Nick
|
|
From: Olivier D. <dr...@sh...> - 2002-02-01 20:58:05
|
Nevermind. I'm stupid. I tried to add with anonymous :o! Sorry, -Oli On Fri, Feb 01, 2002 at 03:55:39PM -0500, Olivier Dragon wrote: > On Fri, Feb 01, 2002 at 05:53:58PM +0000, Dave Cross wrote: > > On Fri, Feb 01, 2002 at 09:35:59AM -0500, Olivier Dragon (dr...@sh...) wrote: > > > I think docs can now be uploaded. Nobody complained about them. Dave, > > > would you do it or tell me where I should upload/import(cvs) them? > > > Should they be in HTML format for the SF website? > > > > Please stick then into the 'docs' sub-project in POD format. I'll whip them > > thru pod2html tomorrow and stick them on the site. > > I'm not too familiar with CVS so I might have done something wrong, but > I tried to upload the docs in the repository and I got this: > > $ cvs-nms-command add HOWTO.developer.pod > cvs [server aborted]: "add" requires write access to the repository > > Is there something I should do to get write access? I'm signed up as a > developer :o| > > -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 -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Olivier D. <dr...@sh...> - 2002-02-01 20:51:23
|
On Fri, Feb 01, 2002 at 05:53:58PM +0000, Dave Cross wrote: > On Fri, Feb 01, 2002 at 09:35:59AM -0500, Olivier Dragon (dr...@sh...) wrote: > > I think docs can now be uploaded. Nobody complained about them. Dave, > > would you do it or tell me where I should upload/import(cvs) them? > > Should they be in HTML format for the SF website? > > Please stick then into the 'docs' sub-project in POD format. I'll whip them > thru pod2html tomorrow and stick them on the site. I'm not too familiar with CVS so I might have done something wrong, but I tried to upload the docs in the repository and I got this: $ cvs-nms-command add HOWTO.developer.pod cvs [server aborted]: "add" requires write access to the repository Is there something I should do to get write access? I'm signed up as a developer :o| -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Olivier D. <dr...@sh...> - 2002-02-01 19:50:13
|
How's this? #!/usr/bin/perl -wT use strict; use ...; . . . # 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 # # 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"; my $baseurl = "/mywebpage"; my ...; . . . # # USER CONFIGURATION << END >> # ---------------------------- # (no user serviceable parts beyond here) *code* On Fri, Feb 01, 2002 at 12:44:55PM -0500, Joseph F. Ryan wrote: > I really don't like that first ################### line; also, i think you > should bring "use strict" to under the shebang > > At 09:33 AM 2/1/2002 -0500, you wrote: > >Hi everyone, > > > >I was just wondering if people has figured out how to have cvs put the > >log in a different file, or if anything has been tried. > > > >On a related note, I've changed the header skeleton (see below). > >Please have a look at it and let me know if it's good. If nobody > >complains I'll make the changes tomorrow. If the log issue isn't > >resolved I'll simply put this right after the log (except for #!). -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Dave C. <da...@da...> - 2002-02-01 19:17:10
|
On Fri, Feb 01, 2002 at 09:35:59AM -0500, Olivier Dragon (dr...@sh...) wrote: > I think docs can now be uploaded. Nobody complained about them. Dave, > would you do it or tell me where I should upload/import(cvs) them? > Should they be in HTML format for the SF website? Please stick then into the 'docs' sub-project in POD format. I'll whip them thru pod2html tomorrow and stick them on the site. Dave... -- Don't dream it... be it |
|
From: Wizard <wi...@ne...> - 2002-02-01 14:58:56
|
> # USER CONFIGURATION << END >> > # ---------------------------- > # (no user servicable parts beyond here) You forgot "servicable" (spelling - should be serviceable). Grant M. |
|
From: Olivier D. <dr...@sh...> - 2002-02-01 14:31:39
|
I think docs can now be uploaded. Nobody complained about them. Dave, would you do it or tell me where I should upload/import(cvs) them? Should they be in HTML format for the SF website? -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Olivier D. <dr...@sh...> - 2002-02-01 14:28:43
|
Hi everyone, I was just wondering if people has figured out how to have cvs put the log in a different file, or if anything has been tried. On a related note, I've changed the header skeleton (see below). Please have a look at it and let me know if it's good. If nobody complains I'll make the changes tomorrow. If the log issue isn't resolved I'll simply put this right after the log (except for #!). #!/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 # 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 ...; . . . # # USER CONFIGURATION << END >> # ---------------------------- # (no user servicable parts beyond here) *code* -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Olivier D. <dr...@sh...> - 2002-02-01 13:33:51
|
----- Forwarded message from "Joseph F. Ryan" <rya...@os...> -----
>From oli Fri Feb 1 08:20:13 2002
Envelope-to: oli@localhost
Delivery-date: Fri, 01 Feb 2002 08:20:13 -0500
To: Olivier Dragon <dr...@sh...>
From: "Joseph F. Ryan" <rya...@os...>
Subject: Re: [Nms-cgi-devel] Simple Search problems
At 11:48 PM 1/31/2002 -0500, you wrote:
>On Thu, Jan 31, 2002 at 11:07:27PM -0500, Joseph F. Ryan wrote:
>> I was fixing a typo in the simple search config description when I decided
>> to give it a try. It didn't work. Detaint_dirname killed the script
>> (there were no directory names which should have killed it), and I
>couldn't
>> get the recursion to work with ('*.html, */*.html, */*/*.html,
>> */*/*/*.html). Did we decide on another method? Perhaps we should have
>> recursion on by default if $Emulate_Matts_Code is set to 0, and keep the
>> old method if it is set to 1.
>
>I wasn't there when the scripts were implemented but crashers are
>definetly issues that need to be addressed. ('*.html, */*.html, */*/*.html,
>*/*/*/*.html) ... is that just a typo or are you missing a ' before the
>closing bracket?
it was just an example. it is actually: ('*.html', '*/*.html',
'*/*/*.html', '*/*/*/*.html')
>> Also, I'd like to implement sorted results if $Emulate_Matts_Code is
>set to
>> 0.
>
>If you can do better than google :o) Just kidding. Sorted results would
>be AWESOME! What would you base the sorting on? I've tried to implement
>a sort myself for search results and it's pretty hard to get it right.
>There is more to take into account than just the frequency of keywords
>in a document (although that's a pretty good start -- for 1 word search
>it's pretty much the only thing to do, for multiple words you have two
>keywords or more to count frequency -> which will give better results?
>10-1 or 4-4? Also as the google theory says, how many words in between
>those two words -> closer = better. *insert your favorite sorting method
>here*, etc, etc ... can get pretty complicated if you really want it)
Well, since it is simple, I was just planning on sorting by hits, nothing
as complex as what I have for advanced search (which reminds me, I need to
work on that some more)
----- End forwarded message -----
--
+----------------------------------------------+
| Olivier Dragon dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+
|
|
From: Dave C. <da...@da...> - 2002-02-01 07:13:14
|
On Thu, Jan 31, 2002 at 09:46:02PM -0500, Drew Taylor (dr...@dr...) wrote: > Hi, > > I'm modifying formmail for a project tonight and have a couple thoughts: [snipped - some good ideas] Drew, This stuff would be better sent to the developers' list. The support list is for end-user problems. Thanks, Dave... -- Don't dream it... be it |
|
From: Olivier D. <dr...@sh...> - 2002-02-01 04:44:49
|
On Thu, Jan 31, 2002 at 11:07:27PM -0500, Joseph F. Ryan wrote:
> I was fixing a typo in the simple search config description when I decided
> to give it a try. It didn't work. Detaint_dirname killed the script
> (there were no directory names which should have killed it), and I couldn't
> get the recursion to work with ('*.html, */*.html, */*/*.html,
> */*/*/*.html). Did we decide on another method? Perhaps we should have
> recursion on by default if $Emulate_Matts_Code is set to 0, and keep the
> old method if it is set to 1.
I wasn't there when the scripts were implemented but crashers are
definetly issues that need to be addressed. ('*.html, */*.html, */*/*.html,
*/*/*/*.html) ... is that just a typo or are you missing a ' before the
closing bracket?
> Also, I'd like to implement sorted results if $Emulate_Matts_Code is set to
> 0.
If you can do better than google :o) Just kidding. Sorted results would
be AWESOME! What would you base the sorting on? I've tried to implement
a sort myself for search results and it's pretty hard to get it right.
There is more to take into account than just the frequency of keywords
in a document (although that's a pretty good start -- for 1 word search
it's pretty much the only thing to do, for multiple words you have two
keywords or more to count frequency -> which will give better results?
10-1 or 4-4? Also as the google theory says, how many words in between
those two words -> closer = better. *insert your favorite sorting method
here*, etc, etc ... can get pretty complicated if you really want it)
-Oli
--
+----------------------------------------------+
| Olivier Dragon dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+
|
|
From: Joseph F. R. <rya...@os...> - 2002-02-01 04:07:33
|
I was fixing a typo in the simple search config description when I decided
to give it a try. It didn't work. Detaint_dirname killed the script
(there were no directory names which should have killed it), and I couldn't
get the recursion to work with ('*.html, */*.html, */*/*.html,
*/*/*/*.html). Did we decide on another method? Perhaps we should have
recursion on by default if $Emulate_Matts_Code is set to 0, and keep the
old method if it is set to 1.
Also, I'd like to implement sorted results if $Emulate_Matts_Code is set to 0.
Any thoughts?
|
|
From: Olivier D. <dr...@sh...> - 2002-01-31 13:44:41
|
On Thu, Jan 31, 2002 at 08:25:53AM -0500, Olivier Dragon wrote: > I see how it could be *hard* to generate config automatically but how is > this a security hole if 1.) it doesn't take CGI input 2.) it's run only > once and creates a config file used thereafter? I guess it could become > a security hole if it's done incorrectly and we end up with wrong config > data. I guess I didn't think this through. It's almost certain we won't have write persmission in the cgi-bin directory and therefore we can't generate a config file that is useable (we could always do it in /tmp but then it might not be so useful). Which leaves the option of running a configurator everytime: this sucks cpu power and could be a security issue. All in all, the idea of an automatic configurator isn't so good, IMHO. I think if the user can't figure out they have to edit the script configuration then they shouldn't be allowed to use the script. Same if they can't configure properly. I mean we have fairly extensive READMEs, and, AFAIK, there's not much else we can do to help them. They have to configure the script or else it's useless. -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Olivier D. <dr...@sh...> - 2002-01-31 13:21:41
|
On Wed, Jan 30, 2002 at 06:08:48PM -0500, Joseph F. Ryan wrote: > 1.) Store the Config inline in the file We already doing that, and so is MWS and seeing as his scripts got very popular that way I really wonder why this would be bad, on a user friendliness point of view. I think, to a certain extent, we're maybe underestimating the capabilities of users to change the configuration. Which brings me to my second point below. > 2.) Store the Config in an outside file I doubt this is really as confusing as people may think. If we say where to edit the configuration in both the script and the README file, think the users won't figure it out? We should probably make the config file (if we are to do one) so we can write comments in it (# is probably good for that). I personnally like the config file idea. > 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. Config is *very* specific to each server (url, basedir, baseurl, etc...). Having ``defaults'' per say is bad, unless these are generated automatically, based on pwd(), and apache's httpd.conf. Only problem is to find httpd.conf and hope the server doesn't have a different webserver running or that their version of apache isn't too old ie. has the config in 3-4 different files. Unless someone here knows how to figure out the documentroot and the webserver's DNS otherwise... Maybe this could be a feature that only works with apache (to save us trouble) since most users should fill out the config anyways. > 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 I see how it could be *hard* to generate config automatically but how is this a security hole if 1.) it doesn't take CGI input 2.) it's run only once and creates a config file used thereafter? I guess it could become a security hole if it's done incorrectly and we end up with wrong config data. > 2.) A compiled C script would not be cross-platform > 3.) Not all users have shell access Agreed. And even if they have access to a shell most of them don't know what to do with a shell anyway. I mean half the people won't have touched a shell and the other half will only know DOS. Those that don't probably won't have any trouble configuring the script. The idea of a config file sounds very appealing to me. I think to a certain extent it might be easier to modify than inline config as the user will never see the code (unless they want to). Having a dumb user filling the config inline won't be any better than one filling the config in a separate file. I think the only issues is having two files and do admins let people put config files in the /cgi-bin/? If not, this idea isn't worth much. But I've never been an admin and I don't know any admins either so I don't know what the general practices are. -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: iain t. <ic...@eh...> - 2002-01-31 00:20:20
|
* Joseph F. Ryan (rya...@os...) [31 Jan 2002 10:31]: > At 08:00 PM 1/30/2002 +0000, you wrote: [...] > 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. Could always have the config part within an eval block. Then, if they mess up the syntax, we can give a meaningful error. cheers, -- iain. <http://eh.org/~koschei/> |
|
From: Joseph F. R. <rya...@os...> - 2002-01-30 23:13:13
|
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 |
|
From: Wizard <wi...@ne...> - 2002-01-30 21:12:48
|
> 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 ... I've been writing Perl code since around 1995, and have developed a module that reads all config info from separate config files (name=value). I have used this for several years now. It is very similar to Config::IniFiles, but about 3 times as fast, and makes configuring a script as simple as editing the config file parameters. I use 'use lib "./path-to-pm";' to specify the module location and then use "use Config::DynaConf" to utilize the library. This has worked in every case to-date. Here's the Docs for it (it was offered to the Config::IniFiles group) if anyone's interested: http://www.neonedge.com/perl_tools/Config/ Grant M. |
|
From: Jonathan S. <gel...@ge...> - 2002-01-30 20:31:52
|
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'. 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 | |
|
From: Joseph F. R. <rya...@os...> - 2002-01-30 17:30:07
|
haha, your point was so well made that I missed it completely :) At 04:36 PM 1/30/2002 +0000, you wrote: >On Wed, 30 Jan 2002, Joseph F. Ryan wrote: > > > Is this REALLY necessary? Do we really want to include this in each > > distribution? > > > >Nope. It was presented as a visual aid in the case against using >constants ;-} > >/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 |
|
From: Jonathan S. <gel...@ge...> - 2002-01-30 16:36:54
|
On Wed, 30 Jan 2002, Joseph F. Ryan wrote: > Is this REALLY necessary? Do we really want to include this in each > distribution? > Nope. It was presented as a visual aid in the case against using constants ;-} /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
14 messages has been excluded from this view by a project administrator.
