Ah, fix after Deliverables, plz!
What the heck :-S in the way...
I very much welcome this proposal for two major reasons. The first is that Perl 6 really needs libraries as Rakudo is becoming usable, and the second is that it also needs applications.
The experience so far has shown that the test suite wasn't enough to ensure that changes in the compiler don't break things; real world applications like November (and hopefully this upcoming web framework) usually reveal quite different bugs.
I have no doubt about the qualification of Ilya, Carl and Stephen. All three of them have shown impressive Perl 6 work before.
This sounds like a very useful proposal. This could be the start of more people taking up Perl 6 for real application.
My biggest complaint is that it seems to be building an opinionated framework. Something with a name like Web.pm should do just a few Web related things and nothing else. Dispatching is very framework specific and each framework does it differently, so don't build it into something low level like Web.pm
I'm not against a web framework in Perl6 and it can certainly use Web.pm, URI.pm, HTML::Template, etc modules created as part of this project. But it seems like it should be a separate project and have this one just focus on some web related modules that would make frameworks possible.
I concur the comment above. Web.pm is a very precious name - it should not be appriopriated by just one framework - but rather reserved for the very basic infrastructure that would be reused by many competing frameworks. On the other hand I am somehow sure that this amount of man-weeks will not be enough for creating a full blown, even very basic, framework.
I agree fully with mpeters and zbigniew.
I support this grant, but with a few caveats.
First why I support it :
* Being able to implement simple web applications with perl 6 would be a major step in making perl 6 useful.
* On a personal note, this would probably be enough for me to start playing with it for simple sites.
* The chance to start afresh with a modern web interface that's progressed since the early 90s birth of CGI would be a big step forward.
The caveats :
* Less is more! A web interface framework in perl should be unopinionated, minimal and anything that you would want to customise should be an optional extra.
* One of the problems with CGI (apart from being kind of frozen after becoming part of Core perl) is that it includes a ton of stuff that's not used, and worryingly this project seems to recreate that : creating HTML Tags isn't the job of the cgi interface, neither is worrying about sessions, etc.
* In my humble opinion it would be much wiser to focus on what frameworks like Catalyst or whatever need to build on when porting to Perl 6 - providing stuff like a generic API for cookies, parameters, headers, uris, MIME types on top of mod_parrot, fcgi, or plain old CGI would be way more useful.
Just to chime in with everyone else. I agree, the name is a huge issue. I would be really disappointed to see "Web.pm" taken by a framework and not low-level tools.
If the name were changed, I think building a web framework would be great. Presumably, some useful low-level tools would also fall out of the effort.
From the point of view of a Rakudo developer, I know that having had November being developed on top of Rakudo has been pushing it forward and has led to many bug reports and, in turn, fixes and new test cases. So I'm very keen to see more of that! I've also met and seen the work of all of the team, and know they have all contributed much to the Perl 6 project so far, so I'm confident they'll be able to keep delivering useful stuff. :-)
The "precious" name is not an issue. It's only a short name, and the full name includes and authority (for example an URL, or a digital signature) and a version.
Perl 6 will allow you to load multiple modules with the same short name but different authorities, so if somebody implements Web.pm, it doesn't mean that this name is taken, and must be avoided to keep compatibility.
That said, even if you don't like the actual Web framework, you can still make good use of the HTTP::* modules, the URI parser and so on, which surely will not be opinionated.
Thank you, I am glad to see so many comments! Our goal is to create complete, useful web f/w. But a lot of it`s parts will be naive, and of course this will be only first step to real-world perl6 web f/w and web applications.
(Please, excuse my English. It is not my original language.)
I'd also like to thank everyone for the positive comments and insightful reservations.
About opinionated frameworks: I hear ya, and I can assure everyone that it isn't our mission to cram our own "cool" solutions in the Web space, botching a valuable CPAN name forever.
Our mission is to make it dirt simple for a Perl 6 web programmer to get something out there, be it an almost-static page or the next Flickr. Web's only function in this will be to "make easy things easy and hard things possible", by providing sane defaults and pluggability. We have a plan for how to do this, and we have our own Perl 6 web applications to try it on. Our goal is to push common tasks down into a common module, so that people who come to Perl 6 web programming will say "wow, this is so in line with the rest of Perl 6 -- Things Just DWIM".
If that's opinionated, then, by golly, we're opinionated. :)
The "WebFramework" or "WebFW" or "WebMVC" would be better. I agree that just Web.pm (or is it pm6, p6m?) can be misleading.
It´s a good name, just too much general... unless, of course, you plan to keep adding current and newer technologies (like plugins, AJAX, and who knows what else in the future).
I think this project should wait until having a betaRC1, or betaRC2 of perl6, for developers work on a robust perl6 language.
At this moment perl6 is in alpha versions(only for intern developers), and not intended to developers in general.
The perl6 developers should announce a betaRC, version ready.
I dont know what is the RFC 3986 link(I've checked it).
For grammars please go to the dragon book from Aho, Sethi and Ullman.
That doesn't quite follow Having actual code helps drive feature development by demonstrating where more work is needed and finding the bugs that normal implementor-written test suites don't find.
In other words, writing the Perl 6 equivalent of CGI.pm helps us get to a better Perl 6 beta. It shouldn't be blocked by it.
As in perl6 book says you can use modules from diferent versions something like
use CGI 5.8
I don't know the reason of writing something that is well done works an is stable, maybe if you make somting fot fastcgi it would be better, but using a stable and robust perl6
And please explain what means (the code) of RFC 3986.
quevlar: re grammars, you have something to look forward to when you check out Perl 6, Synopsis 05 in particular.
Re 'something that is well done, works, and is stable', we do believe (as did Juerd in his emails about Web two years ago) that CGI can profitably be superceded by something better. In current Perl 6 development, we don't have direct access to any CPAN modules, and that's both a barrier and a cause for thinking about what we really want. Instead of porting over old stuff, we're increasingly considering doing some things from scratch when it comes to Perl web development.
Finally, I believe RFC 3986 is a syntax specification for Uniform Resource Identifiers. Did you check the link in the post?