This action item is particularly interesting:

"Server: we need to write an App Engine server for testing, local development, and potentially production deployment. (Replace Bigtable with MySQL, Hypertable, Hbase, Couch DB, etc.)"

An open-source production-capable alternative to AppEngine (that uses its APIs) would help defuse the lock-in issues.

Wow, this is a great snapshot into what it will take to move a language to App Engine. Kudos for him taking this up as his 20% project, certainly sounds challenging.

This is awesome. The neat thing is that fitzpatrick will probably be able to actually pull it off. I just hope it'll be able to run Catalyst.

Running Catalyst is a goal. If it turns out that we have some time to really make it nice, I'd prefer to support any framework that uses HTTP::Engine. Right now, that's nothing, but since HTTP::Engine is basically extracted from Catalyst, getting Catalyst to run will be easy. But it also means that we'll get other Perl frameworks like CGI::App (they've indicated interest, anyway), Continuity, Jifty (perhaps), etc.

The Python guys may be happy with one framework... but this is Perl. There's more than one way to do it :)

BTW, I'm a Catalyst core developer, so I'll certainly do everything I can to make working with Catalyst on GAE enjoyable. That's what I want for my applications. But really, getting the web framework to work is the easy part. Getting a Perl that meets Google's requirements is the hard part.

We intend it to.

Or, given the timescale, run HTTP::Engine, which is an extraction of the Catalyst::Engine system that's designed to be used by any framework - i.e. to become a perl equivalent to WSGI - and which Catalyst is going to port to once it's baked.

From what I've seen on the list, Catalyst seems to be running a little ahead at the moment.

Perl and the GAE deserve each other.

The quick description of Sys::Protect (and it's lack of documentation on CPAN so far) make it seem like an implementation of the Safe module with a preconfigured list of unwanted opcodes. I'm interested in know why Safe wasn't considered or how Sys::Protect is related, if at all, to Safe (which I believe has been a standard perl module for quite some time).