CGI.pm V. Here Docs . . . 
Author Message
 CGI.pm V. Here Docs . . .


Quote:

>Yes, cgi-lib is depreciated, and deprecated.

I don't think you understand what 'deprecated' means.  "Deprecated"
does not make sense in this context.  The developers of Perl can say
when a Perl feature is 'deprecated'; this means that they will not
continue to support it, and that it might not be present in a future
version of Perl.

It does not make sense to say that 'cgi-lib is deprecated'.
Deprecated by whom?  By you?  Does that mean you will no longer
support it?  But you never promised to support it in the past, and
nobody expected you to support it, so revoking your support does not
matter.  Will it be absent from a future version of Perl?  So what?
It has never been included with Perl.

Quote:
>No development is done on
>cgi-lib and no new versions are released.

That is a good thing, not a bad thing.

No development is done because cgi-lib.pl is *complete*.
It does what it was designed to do, and it does it effectively.
No bugs have been reported in it for *six years*.

I would think that not having to constantly install new incompatible
versions of the same package would be a considered benefit.  Yuou can
be absolutely sure that your program will never break when you
'upgrade' to an incompatible version of cgi-lib.pl, because there are
no incompatible versions and no 'upgrades'.  

It is sad that greedy software companies have inured us to buggy,
incomplete software that is followed by an endless stream of
enhancements and bug fixes.  We have actually forgotten that this is
not the only kind of sofware that exists!  If we are told that there
is software with no bugs and no missing features, we cannot believe
it, and we suppose that there must be something wrong.

This is very frustrating to anyone who maintains a mature, effective
piece of software.  You have to field constant questions about why
there has not been a new release in nine months.  People are skeptical
when you tell them it is because there are no bugs and that no new
features are necessary.  They would rather assume that you have
abandoned the package.

Quote:
>On the other hand, new versions of browsers and web servers are
>released.

This is pure FUD.  CGI has not changed.  The current version is still
1.1, standardized in 1995.  CGI 1.2 was never completed, and no
servers support it.

rd
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print



Tue, 30 Sep 2003 03:00:32 GMT  
 CGI.pm V. Here Docs . . .

Quote:
} No development is done because cgi-lib.pl is *complete*.
} It does what it was designed to do, and it does it effectively.
} No bugs have been reported in it for *six years*.
}
} I would think that not having to constantly install new incompatible
} versions of the same package would be a considered benefit.  Yuou can
} be absolutely sure that your program will never break when you
} 'upgrade' to an incompatible version of cgi-lib.pl, because there are
} no incompatible versions and no 'upgrades'.  
}
} It is sad that greedy software companies have inured us to buggy,
} incomplete software that is followed by an endless stream of
} enhancements and bug fixes.

Amen -- you left out one other thing: we're inured to programs that have
overly complicated, vague and constantly changing requirements and so can
*never* be said to be "done".

It is actually a surprising (and fairly rare!) testament to the stability
of the CGI spec and the careful setup of the functional requirements for
cgi-lib that it is really _done_...  I wish that *ANY* program I've ever
written could mature enough to get to that lofty plateau..:o)

  /Bernie\
--
Bernie Cosell                     Fantasy Farm Fibers

    -->  Too many people, too few sheep  <--          



Tue, 30 Sep 2003 23:27:05 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. CGI.pm V. Here Docs . . .

2. Delphi 2.0 & Apollo 2.52

3. CGI.pm vs. Base.pm

4. Docs for CGI.pm!

5. Reference docs for CGI.PM??

6. CGI-modules vs. CGI.pm

7. cgi-lib.pl vs CGI.pm?

8. cgi-lib.pl vs CGI.pm

9. cgi.pm .vs. cgi-lib.pl

10. Master-detail...active/inactive consequences

11. Any suggestion???

12. Speeding up filters... and DBGrids.

 

 
Powered by phpBB® Forum Software