5 ms·

Perl on App Engine

bprater 18y ago
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.
staunch 18y ago
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.
- hsmyers 18y ago
  From what I've seen on the list, Catalyst seems to be running a little ahead at the moment.
- mst 18y ago
  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.
- jrockway 18y ago
  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.
benreesman 18y ago
Perl and the GAE deserve each other.
DocSavage 18y ago
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.
thwarted 18y ago
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).

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.

staunch 18y ago

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.

hsmyers 18y ago
From what I've seen on the list, Catalyst seems to be running a little ahead at the moment.
mst 18y ago
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.
jrockway 18y ago
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.

benreesman 18y ago

Perl and the GAE deserve each other.

DocSavage 18y ago

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.

thwarted 18y ago

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).