On Tue, Sep 26, 2000 at 04:41:21AM -0400, Alan Gutierrez wrote:
> > > > > Robust input parsing: yes.
> > > >
> > > > > General purpose output formatting: no, [...]
> > > >
> > > > > Rudimentary HTTP header emission: probably.
>
> So this is the definition of first-class?
Have you read the RFC?
Have you read the message you're quoting here? In full? In context?
Here's the abstract again:
Perl is frequently used in CGI environments. It should be
as easy to write CGI programs with perl as it is to write
commandline text filters.
For the purposes of this discussion *this* is what first class means.
> As I've said before,
> first-class CGI to me means a language where I can focus on the HTML or
> XML I am creating. An example of a first-class CGI language is ASP or my
> beloved HTML::Embperl. I don't bother with CGI anymore, and when I did I
> was content with CGI.pm.
Have you been reading this thread? I've already said in at least
one occasion that playing favorites between embperl, mason, template
toolkit, text::template, Format, autoformat, xml::writer and such
is *NOT* the intent of this RFC.
Please stop inferring that this should be a way of getting *your* own
*personal* favorite CGI module included into the core, especially
when you say later it wouldn't make sense.
I'm not saying any of that.
> It seems like we are talking about pulling some functions from a module
> to the core. And for no real good reason. Is query string parsing or
> header processing so time consuming that it must be implemented in C?
It seems you are mistaken. We are not talking about implementing
string or header processing in C. Please re-read this thread.
> For any sizeable application input and headers will not be enough.
> You'll need cookies and redirection certainly. At which point you will
> load CGI.pm anyway (if you are bothering to create this in classic CGI).
Please re-read the CGI specification as well. Cookies and redirection
are both HTTP headers, and do not require loading CGI.pm.
Z.
