Re: CGI Session management (was Re: the CGI.pm in Perl 6)
* Yuval Kogman [EMAIL PROTECTED] [2006-09-12 12:05]: There are *so* many ways to do session handling that lugging them all into CGI.pm will just make a mess. Agreed, but maybe this is a case where it would make sense to do something like what Perl 6 does for OO vs Perl 5, ie provide one good default set of options that people can use without thinking too much about it when they first get started? F.ex., I could imagine that CGI.pm6 would provide a framework for plugging in session implementations somehow (insert your wisdom from the Catalyst design here f.ex.), and then comes with an easy to set up default session store that would be configured in the course of Perl 6 installation. This way, it would work the way PHP works: when the sysadmin installs it, it is automatically fully set up to provide sessions somehow, and only the people who really need performance or special features need to think harder about it. (Which they can, because the whole thing is still pluggable.) I think we stand to gain a lot from adopting the PHP/Python “batteries included” attitude (cf. Elaine’s Law). (I note that Catalyst is not holding up so well there… although it has made great strides, in all fairness.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: the CGI.pm in Perl 6
* Trey Harris [EMAIL PROTECTED] [2006-09-10 23:50]: But the HTML methods are used everywhere. And the more novitiate the programmer, the more likely they are to be using them spaghetti-like throughtout their code. If they discover that every time they see a Cstart_form it's going to entail new coding, they're going to rapidly get discouraged about porting to Perl 6. I see that argument. So build a lean, well-designed CGI module, but also offer a CGI5 module that aggregates the CGI stuff along with HTML::Gen and whatnot into a CGI.pm5-compatible API melange for easy porting. No need to drag old mistakes along for all eternity just for the sake of their familiarity. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
F.ex., I could imagine that CGI.pm6 would provide a framework for Please, please, please, let us not call this module CGI or anything closely resembling it. This will only fool a lot of inexperienced Perl 5 programmers, and start a lot of fuss about the interface being incompatible. And, of course, the name CGI is just totally *WRONG*, for several reasons, *especially* if we provide Session support built in. This way, it would work the way PHP works: when the sysadmin installs it, it is automatically fully set up to provide sessions somehow, and only the people who really need performance or special features need to think harder about it. (Which they can, because the whole thing is still pluggable.) Agreed. We can safely default to file based sessions, like PHP does. This is one of the things that PHP got right! Inefficiency, cruft accumulating in /tmp, and the possible inavailability of a tmp directory is not our problem. That's a sysadmin thing. We can easily make this work out of the box for 95%[1] of all installations. [1] Like 53.4% of all statistics, this one is made up and based only on 0.5% actual research that nobody can actually recall, and based precisely 88.445% on the writer's own experience. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Charsets in HTTP (was: the CGI.pm in Perl 6)
At 7:38 PM +0200 9/16/06, A. Pagaltzis wrote: * Darren Duncan [EMAIL PROTECTED] [2006-09-09 20:40]: 4. Make UTF-8 the default HTTP response character encoding, and the default declared charset for text/* MIME types, and explicitly declare that this is what the charset is. The only time that output should be anything else, even Latin-1, is if the programmer specifies such. No, please don't. For unknown MIME types, the charset should be undeclared. In particular, `application/octet-stream` should never have a charset forced on it if one is not assigned by the client code explicitly. Likewise, for `application/xml` and `application/*+xml`, a charset should NEVER be explicitly declared, as XML documents are self-describing, whereas declaring a charset forces using the charset declared in the HTTP header. This is very unwise (cf. Ruby's Postulate). Look again; I was only specifying that a default charset is used for text/* MIME types, not non-text/* MIME types; the latter would typically have no charset as you say. 5. Similarly, default to trying to treat the HTTP request as UTF-8 if it doesn't specify a character encoding; fallback to Latin-1 only if the text parts of the HTTP request don't look like valid UTF-8. This is not just unwise, it is actually wrong. Latin-1 is the default for `text/*` MIME types if no charset is declared. Using a different charset in violation of the HTTP RFCs is __BROKEN__. Okay, I retract that suggestion. Because the official HTTP spec says no-explicit-charset-means-Latin1. In fact, now that I'm writing all this out, I am starting to think that maybe CGI.pm6 should simply punt on charsets as CGI.pm does. Otherwise, the code and API would have to have able to deal with the full complexity of charsets in HTTP, and the docs would have to explain it, which is no picnic at all. I disagree. Regardless of the details, a Perl 6 replacement for CGI.pm *should* handle character set issues. Its users should simply be able to pull out correctly interpreted ready-to-use Str values when the HTTP request content type is text, and not have to know about what character set was used in the request. Analagously, if the user takes their Str values and supplies them to an HTTP response whose content type is text, they should not have to specify an output encoding if they don't want to, and UTF-8 is the best default because it can handle all possible characters that the Str repetoire can represent. The CGI.pm replacement by no means has to do the dirty work of processing encodings itself, such as mapping bytes to chars etc. Those details would be handled by something else, such as either Perl 6 itself or a Perl 6 analogy to Encode.pm. -- Darren Duncan
