Re: [Nms-cgi-devel] Welcome

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

From: Jonathan Stowe <gel...@ge...>
Date: 11/13/01 8:31:22 AM

>On Mon, 12 Nov 2001, Dave Cross wrote:
>
>> Hey look, we have people on the list. Thanks for 
>> joining :)
>>
>> Some things that need doing:
>>
>> 1/ Test, test, test. On as many platforms as possible.
>>
>
> Maybe we ought to get a Tripod or Virtual Avenue account -
> as this is likely to be very much the environment most of 
> the user base will be in - besides we won't mind so much 
> if the site gets r00ted ;-}

Good idea. 

>> 2/ Document, document, document. Currently the scripts 
>> have READMEs that are very closely (in some cases, _too_ 
>> closely) modelled on Matt's. Better docs are important.
>
> We probably want to come up with a boilerplate to do with 
> the general configuration and troubleshooting of CGI 
> programs.  We shouldnt worry too much about not 
> reinventing stuff that can be found elsewhere because it 
> is unlikely that the target audience are going to find 
> the stuff in the first place - give them enough to stop 
> them from becoming guest of honour at a flamewar on 
> comp.lang.perl.misc.

Yep. I'd love it if we had a really simple guide to installing
CGI scripts included with every nms tarball. We should assume
no knowledge at all on the part of the users.

>> 3/ Peer review. Most of the code was written by me in 
>> the course of a ten hour hackfest one weekend. It can no 
>> doubt be improved. I'd love suggestions.
>
> In the first instance I have taken the duplicated code 
> out of some of the files (it looks like you may have 
> done ':r' in vi twice :)

Hmm... unlikely as I'm an emacs user :) Don't where that came
from.

> and added CGI::Carp in those places where the script 
> might die() this will at least produce something 
> moderately less confusing than a plain 500 in the event
> of failure

I don't like this idea. I think that web servers give vanilla
500 errors for a good reason. The more information a user gets
from an error message then the more information they have about
the workings of the script and the more chance they have of cracking
the site.

I'm happy to have CGI::Carp included in the scripts and used
for development and debugging - but I'd like it commented out
of anything checked into CVS.

> - I think in the long term it would be best to come up 
> with a slightly different and more configurable strategy 
> that can be used consistently across the programs.

Agreed.

> I think something that we ought to be looking at in the 
> programs is introducing better ways of doing things - it 
> is not absolutely necessary that we emulate the original 
> programs down to the strange methods of storage (for 
> instance) if they are being deployed in a green field site
> that has not yet been tainted with Matt's scripts.  

But don't forget, that we are supposed to be creating _drop-in_
replacements for MSA. I see a lot our users being people who
have Matt's scripts in place who want to move to something "better"
(for some meaning of the word). It's therefore important that
we can deal with all of Matt's baroque interface ideas.

> You will for instance see in 'ffa.pl' the variable 
> $emulate_matts_ffa : although not completely implemented 
> yet when this is switched off the program will store its 
> data in a flat file and generate the HTML page on the fly 
> rather than updating the HTML page directly as it does 
> now.  The guestbook and wwwboard should have this option 
> as well although we do have to retain compatibility with
> Matt's peculiar storage mechanisms if we are to hope to 
> encourage to upgrade to our programs :)  I thought I had 
> started doing this with the guestbook but I can't find 
> the code anywhere :(

Agreed. Maybe rename the variable to $emulate_matts_code and
use the same one in all scripts. The default should, of course,
be on.

>> 4/ Comments. At last week's london.pm meeting, it was 
>> suggested to me that a higher than usual level of 
>> comments might be a good idea - given the number of 
>> people that learned Perl from MSA.
>
> I've started on that with FFA - elucidating in some 
> detail what the configurable bits mean. 

Great. I'll take a look at those later.

> I would consider it moot whether we should start 
> introducing a quantity of tutorial material into the 
> code - perhaps we could provide an annotated set of 
> source as part of the project documentation (actually 
> this might be a valuable project in its own right).

Damn right. Actually, I'm considering writing it all up into
something that might just become a replacement for Matt Wright's
excreable book :)

[snip stuff about IIS fuckwittage]

Thanks for the detail. That's something that needs to make it
into the docs. Probably a FAQ.

> Oh yeah by the time you read this I will have tinkered 
> with the CVS so that you can check out the whole thing 
> with 'co NMS' - this does mean that you will need to edit 
> CVSROOT/modules if you add a new module - that'll be
> man 5 cvs to you ;-}

Cool. Thanks.

Dave...

-- 
<http://www.dave.org.uk>

"Let me see you make decisions, without your television"
   - Depeche Mode (Stripped)