Menu
▾
▴
nms-cgi-devel
|
From: Dave C. <da...@da...> - 2002-01-29 13:33:47
|
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 |
|
From: Wizard <wi...@ne...> - 2002-01-29 14:05:04
|
> . > # > # END USER CONFIGURATION > # (no user servicable parts beyond here) > # How 'bout "USER CONFIGURATION - END" or "USER CONFIGURATION <<END>>" or some such? "END USER CONFIGURATION" is somewhat ambiguous, as "END USER" could be misinterpreted (can you say "nit-pik"?). Also, "servicable" should be "serviceable". Grant M. |
|
From: Dave C. <da...@da...> - 2002-01-29 14:20:16
|
On Tue, Jan 29, 2002 at 09:03:12AM -0800, Wizard (wi...@ne...) wrote: > > . > > # > > # END USER CONFIGURATION > > # (no user servicable parts beyond here) > > # > How 'bout "USER CONFIGURATION - END" or "USER CONFIGURATION <<END>>" or some > such? "END USER CONFIGURATION" is somewhat ambiguous, as "END USER" could be > misinterpreted (can you say "nit-pik"?). > Also, "servicable" should be "serviceable". Agree on both counts. Dave... -- .sig missing... |
|
From: Sam S. <sa...@us...> - 2002-01-29 14:24:48
|
On Tue, 29 Jan 2002, Dave Cross wrote:
> # 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 ...;
Could we put those are the top of the file, above the
use Foo;
lines?
That way, people don't have to scroll past anything.
Sam
--
Bitterness: Never be Afraid to Share Your Dreams with the World, Because
There's Nothing the World Loves More Than the Taste of Really Sweet Dreams
|
|
From: Dave C. <da...@da...> - 2002-01-29 14:39:22
|
On Tue, Jan 29, 2002 at 02:29:07PM +0000, Sam Smith (sa...@us...) wrote: > On Tue, 29 Jan 2002, Dave Cross wrote: > > # 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 ...; > > Could we put those are the top of the file, above the > use Foo; > lines? > > That way, people don't have to scroll past anything. Well, they can't go above the "use strict". Or rather, they could but it wouldn't make much sense. Dave... -- Don't dream it... be it |
|
From: Olivier D. <dr...@sh...> - 2002-01-29 17:01:16
|
On Tue, Jan 29, 2002 at 01:29:44PM +0000, Dave Cross wrote: > * Constants I guess a majority of people seems to think that constants aren't such a good idea after all. May the Lord save us all (joking). Fine with me. > * New documents I've got a few changes to make: (inside []) RULES.coding * Only [standard] modules included ... HOWTO.developer ... accessing the code in our CVS repository. [It is also strongly recommended to join the developers' mailing list at <http://lists.sourceforge.net/mailman/listinfo/nms-cgi-devel>] -Dave Cross, Project Manager > * Program header comments Seems like people don't like the "flower box" idea. Could we at least put a visual separation line between sections for people that skim through? Either a dash line on top of the section header or simply underline the section header titles with a dash line. > * CHANGELOG file hmm... I don't know a direct way of doing this. Is CVS doing this automatically? If so, why doesn't it do it for other files like README and MANIFEST? If CVS isn't doing this automatically, turn logging in *.pl off and direct it to CHANGELOG. Or (don't know if we're allowed this on SourceForge) run a cron job that does `cvs log > CHANGELOG` every half hour or so foreach $project. I don't know the feasability of this since I've started using CVS about 2 weeks ago and SourceForge yesterday ;o) but here's an idea... -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Jonathan S. <gel...@ge...> - 2002-01-29 21:12:37
|
On Tue, 29 Jan 2002, Olivier Dragon wrote:
> On Tue, Jan 29, 2002 at 01:29:44PM +0000, Dave Cross wrote:
> > * Constants
>
> I guess a majority of people seems to think that constants aren't
> such a good idea after all. May the Lord save us all (joking).
> Fine with me.
>
I'm not sure that anyone is saying that constants are a bad thing - it's
just that the implementation doesn't hit the right note. Constants should
just behave like variables that can't be changed (in my and evidently
Dave's opinion ), but Constant subroutines don't : they can't be
interpolated directly into a string, they change the apparent precedence
of expressions the are used in and you get a possibly confusing compile
time error when you do try to assign to it (I know that the computer
science bods in the house are going to come back and say that it should be
a compile time error, but hey this Perl not some other language).
You can have constant scalars but I have to say that it is equally nasty:
#!/usr/local/old/bin/perl -w
use strict;
use vars qw($foo);
*foo = \'bar';
$foo = 'gag';
Or if you want to hide the implementation away you could have the even
more appalling:
#!/usr/local/old/bin/perl -w
use strict;
BEGIN
{
@main::config_vars = qw($foo);
};
use vars @main::config_vars;
$foo = 'zub';
foreach my $var (@main::config_vars)
{
(my $symbol = $var) =~ s/^\$//;
no strict 'refs';
$var = eval "$var";
*{$symbol} = eval "\\'$var'";
}
$foo = 'gag';
(Ohmigod - two string evals in one teensy piece of code :)
Of course then all of the variables thus abused must be package globals
...
You could use a tied scalar or some XS code but neither of these will fit
our didactic aims, and you could use attributes but these don't work with
the older perls ...
I'm having a little difficulty with the tied scalar part - that would be
the best bet though if we could hide the implementation details ...
/J\
> > * New documents
>
> I've got a few changes to make: (inside [])
>
> RULES.coding
> * Only [standard] modules included ...
>
> HOWTO.developer
> ... accessing the code in our CVS repository.
>
> [It is also strongly recommended to join the developers' mailing list at
>
> <http://lists.sourceforge.net/mailman/listinfo/nms-cgi-devel>]
>
> -Dave Cross, Project Manager
>
> > * Program header comments
>
> Seems like people don't like the "flower box" idea.
>
> Could we at least put a visual separation line between sections for
> people that skim through? Either a dash line on top of the section
> header or simply underline the section header titles with a dash line.
>
> > * CHANGELOG file
>
> hmm... I don't know a direct way of doing this. Is CVS doing this
> automatically? If so, why doesn't it do it for other files like
> README and MANIFEST?
>
> If CVS isn't doing this automatically, turn logging in *.pl off and
> direct it to CHANGELOG. Or (don't know if we're allowed this on
> SourceForge) run a cron job that does `cvs log > CHANGELOG` every half
> hour or so foreach $project. I don't know the feasability of this
> since I've started using CVS about 2 weeks ago and SourceForge
> yesterday ;o) but here's an idea...
>
> -Oli
>
>
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Olivier D. <dr...@sh...> - 2002-01-29 22:03:37
|
On Tue, Jan 29, 2002 at 09:02:07PM +0000, Jonathan Stowe wrote: > On Tue, 29 Jan 2002, Olivier Dragon wrote: > > On Tue, Jan 29, 2002 at 01:29:44PM +0000, Dave Cross wrote: > > I guess a majority of people seems to think that constants aren't > > such a good idea after all. May the Lord save us all (joking). > > Fine with me. > > > > I'm not sure that anyone is saying that constants are a bad thing - it's > just that the implementation doesn't hit the right note. That's what I meant by "not such a good idea" :o) You captured the essence of it. It's not a Bad Thing(tm), just not appropriate in the current > You can have constant scalars but I have to say that it is equally nasty: > (* nasty stuff snipped *) Gotcha! :o) -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Jonathan S. <gel...@ge...> - 2002-01-30 09:09:31
|
On Tue, 29 Jan 2002, Jonathan Stowe wrote:
>
> I'm having a little difficulty with the tied scalar part - that would be
> the best bet though if we could hide the implementation details ...
>
I was having a little moment of brainlessness with this:
#!/usr/bin/perl -w
use strict;
BEGIN
{
@main::config_vars = qw($foo);
};
use vars @main::config_vars;
$foo = 'zub';
foreach my $var (@main::config_vars)
{
no strict 'refs';
$main::tmp = eval "$var";
$var =~ s/\$//g;
my $obj = tie ${$var}, 'ReadOnly';
${$var} = $main::tmp;
use strict 'refs';
$obj->readonly(1);
}
$foo = 'gab';
BEGIN
{
package ReadOnly;
sub TIESCALAR
{
my ( $class ) = @_;
my $gab = {readonly => 0, value => ''};
return( bless $gab, $class);
}
sub STORE
{
my ( $self, $value ) = @_;
if ( $self->readonly )
{
die 'No you dont matey';
}
else
{
$self->{value} = $value;
}
}
sub FETCH
{
my ( $self) = @_;
return $self->{value};
}
sub readonly
{
my ( $self, $readonly ) = @_;
if ( defined $readonly )
{
$self->{readonly} = $readonly;
}
return $self->{readonly};
}
}
Equally shocking as I am sure you will agree.
The XS version is a lot nicer - shame we can't use that:
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
MODULE = ReadOnly PACKAGE = ReadOnly
void
readonly(sv)
SV *sv
PPCODE:
SvREADONLY_on(sv);
:)
I'm sure there is already a module that does this on CPAN, but I've
reinvented it anyhow (by the time I'd done the above and got a harness
to test it I'd written a module) ... if anyone is interested it can be
found in its entirety at:
<http://petunia.gellyfish.com/modules/ReadOnly-1.2.tar.gz>
Or will be when I get to the office.
/J\
--
Jonathan Stowe |
<http://www.gellyfish.com> | This space for rent
|
|
|
From: Joseph F. R. <rya...@os...> - 2002-01-30 15:36:00
|
Is this REALLY necessary? Do we really want to include this in each
distribution?
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 think using constants for the config is bad for these reasons:
1.) Clutters the code (see below) - don't forget that we are trying to
teach good practice
2.) Changes look from MWS - upgraders will get confused
3.) Changes code - anyplace that we used variables in a normal Perl fashion
would need to be restructured
4.) Less stable - NMS is there partially to teach - what happens when a
newbie starts changing the code, and can't figure out why he is getting a
fatal error when he assigns to a variable? He's going to get discouraged
and quit.
5.) Unnecessary - The goddamn code works fine now, why do we need to change
it? I honestly don't see ANY advantage(s).
At 08:24 AM 1/30/2002 +0000, you wrote:
>On Tue, 29 Jan 2002, Jonathan Stowe wrote:
> >
> > I'm having a little difficulty with the tied scalar part - that would be
> > the best bet though if we could hide the implementation details ...
> >
>
>
>I was having a little moment of brainlessness with this:
>
>#!/usr/bin/perl -w
>
>use strict;
>
>BEGIN
>{
> @main::config_vars = qw($foo);
>};
>
>
>use vars @main::config_vars;
>
>$foo = 'zub';
>
>
>foreach my $var (@main::config_vars)
>{
>
> no strict 'refs';
>
> $main::tmp = eval "$var";
>
> $var =~ s/\$//g;
>
> my $obj = tie ${$var}, 'ReadOnly';
>
> ${$var} = $main::tmp;
>
> use strict 'refs';
>
> $obj->readonly(1);
>
>
>}
>
>$foo = 'gab';
>
>
>BEGIN
>{
>
> package ReadOnly;
>
> sub TIESCALAR
> {
>
> my ( $class ) = @_;
>
>
> my $gab = {readonly => 0, value => ''};
>
> return( bless $gab, $class);
> }
>
>
> sub STORE
> {
> my ( $self, $value ) = @_;
>
>
> if ( $self->readonly )
> {
> die 'No you dont matey';
> }
> else
> {
> $self->{value} = $value;
> }
> }
>
> sub FETCH
> {
> my ( $self) = @_;
>
>
> return $self->{value};
> }
>
> sub readonly
> {
> my ( $self, $readonly ) = @_;
>
> if ( defined $readonly )
> {
> $self->{readonly} = $readonly;
> }
>
> return $self->{readonly};
> }
>
>}
>
>
>Equally shocking as I am sure you will agree.
>
>The XS version is a lot nicer - shame we can't use that:
>
>#include "EXTERN.h"
>#include "perl.h"
>#include "XSUB.h"
>
>
>MODULE = ReadOnly PACKAGE = ReadOnly
>
>
>void
>readonly(sv)
>SV *sv
> PPCODE:
> SvREADONLY_on(sv);
>
>
>:)
>
>
>I'm sure there is already a module that does this on CPAN, but I've
>reinvented it anyhow (by the time I'd done the above and got a harness
>to test it I'd written a module) ... if anyone is interested it can be
>found in its entirety at:
>
> <http://petunia.gellyfish.com/modules/ReadOnly-1.2.tar.gz>
>
>Or will be when I get to the office.
>
>/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 | |
|
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 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: 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: 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: 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: 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: 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: Nick C. <ni...@cl...> - 2002-01-30 01:00:51
|
On Tue, Jan 29, 2002 at 12:05:31PM -0500, Olivier Dragon wrote: > > HOWTO.developer > ... accessing the code in our CVS repository. > I think there should be a note here about how important it is to test the scripts before checking them into CVS. -- Nick |
Thanks for helping keep SourceForge clean.
X