2009Q1 Grant Proposal: Web.pm - a lightweight web framework for Perl 6


Ilya Belikin, Carl Mäsak, Stephen Weeks


Ilya Belikin ([hidden email]), Carl Mäsak ([hidden email]), Stephen Weeks ([hidden email])

Amount Requested:


Ilya: 1320$, for 12h/week.
Carl: 1100$, for 10h/week.
Stephen: 550$, for 5h/week.


Two years ago, Juerd proposed the Web.pm module for Perl 6. Meant to functionally replace Perl 5's CGI.pm, it is a revamping of the fundamentals in order to better serve today's web development needs.

Apart from implementing a working web development toolkit, we intend to integrate templating as a desirable default, make sessions and sticky form values (as described in Juerd's email) work, and organize the framework according to the Model-View-Controller (MVC) pattern and the REST architecture.

The structure of the Web framework will be modular, and a web application writer can choose the parts that make sense for the particular application developed. As the user's application matures, more high-level modules can be swapped in to combat the increasing complexity.

We intend to develop Web.pm in the open, seeking frequent input from people on #perl6 and #parrot, and from the mailing lists perl6-compiler, perl6-users and perl6-language.

Benefits to the Perl Community

Having a simple, well thought-out web development toolkit can be an enormous benefit to Perl 6 and its growing developer community. There is good opportunity at this time to coordinate an effort to create such a toolkit. A web toolkit will increase Rakudo visibility, and bring more people to try Perl 6 programming.

Applications like November show that it is possible to create a Perl 6 web application today, but that much convenience functionality has to be reinvented in the web application itself. The fact that a bridge between Rakudo and Perl 5/CPAN does not exist at this point is an obstacle, but also an opportunity to sit down and think about the parts that we want to improve or remake rather than just inherit.

As the past six months of November clearly show, development of real-world applications is one of the most effective ways to generate feedback to the Rakudo development team, and to help focus on bug fixes and features needed for everyday tasks.


HTTP::Request, HTTP::Response and Web.pm modules that run on the latest release of Rakudo.
A URI module based on RFC 3986, using Perl 6 grammars.
Web::Tags module for (X)HTML tags generation.
Dispatcher and Routines (with REST support) modules for better controllers code organization.
A simple Perl6-ish templater as a replacement for HTML::Template.
A slightly more advanced XML-aware templating system, similar to Python's Genshi.
Three web applications that make use of the Web module. (On the assumption that having three clients to an API gives enough clues about the different needs clients might have.) The first web application will most likely be November, the wiki, and the second Maya, a blogging engine. The third will be a proof-of-concept pastebin for Perl 6 code with color coding.
A tutorial clearly showing the strengths of the Web module framework, why/when it should be used, and how to get started using it.

The modules URI, HTML::Template, and Dispatcher already exist in a working alpha state within the November repository, and are being used to run the wiki engine. Ilya has begun developing the blogging engine Maya.

Ilya will post weekly about progress in Russian on the perl6.ru blog. Carl will blog weekly on use.perl.org. Stephen will blog weekly.

Project Details

The following stages can be identified in providing the above deliverables:

Specifying the basics of a Web framework organized by MVC pattern and following REST principles.
Creating a minimal Web, HTTP, Template and Routines modules that can host a minimal "hello world" web application with a simple form, but following the specification.
Adapting November to run on top of the new Web framework. Much of the infrastructural web code currently residing in November will thereby be the responsibility of the framework instead.
Setting up Maya to use the framework as well. Deploying and start to use it for perl6-blog us soon as possible.
Implementing the framework and applications features possible within the current limits of Rakudo.
Condensing the above experience into a tutorial.


Specifying framework basics: 1 week.
Creating a minimal Web framework: 2 weeks.
Changing November to run on top of the framework: 1 weeks.
Setting up Maya to use the framework: 1 week.
Setting up a proof-of-concept pastebin: 1 week.
Implementing the features possible within the current limits of Rakudo: 4 weeks.
Condensing the above experience into a tutorial: 1 week.

Project Schedule

Specifying framework basics: 1 week.
Creating a minimal Web framework: 2 weeks.
Changing November to run on top of the framework: 1 weeks.
Setting up Maya to use the framework: 1 week.
Setting up a third web application: 1 week.
Implementing the features possible within the current limits of Rakudo: 4 weeks.
Condensing the above experience into a tutorial: 1 week.

We can start in February.


Ilya Belikin has been working with web technologies since 2000, functioning as an all-round project manager, CSS and HTML coder. A Perl developer since 2006, he founded a small web-developing company 2007. He uses Catalyst, TT, and DBIx::Class in his daily work. He is a productive November committer (280+ commits). He sends Rakudo and Parrot bug reports. He is one of the authors of perl6.ru.

Carl Mäsak has been using Perl since 2002, and has been an avid Pugs participant since 2005. He has committed various tests, documentation files and the occasional Haskell patch, totalling over 100 commits. He is a Parrot committer, helping the main Rakudo developers with bug tickets (over 200 so far), patches and minor features. He is one of the co-founders of the November project.

Stephen Weeks has been using Perl since 2004 for web development and sysadmin tasks. He has been a Parrot core developer since Feb 2008, implementing many features in Rakudo.

OK to publish this proposal?



Ah, fix after Deliverables, plz!

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?

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

About this Entry

This page contains a single entry by Alberto Simões published on February 6, 2009 5:16 PM.

2009Q1 Grant Proposal: Perl 6 Pages was the previous entry in this blog.

2009Q1 Grant Proposal: OPener Package is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2