enough talk, time for code

So I've been talking about a railish routing scheme for GAE. Finally after nibbling on the problem whenever I could score some free time, I've got something that's working (if not perfect) here - railsish_gae.

In short, it's a mechanism for automagically loading up a controller, executing an action, and rendering a template based on the URL that was called.

Dunno if it'll be useful to anyone else, but I'm just glad I can quit OCD'ing on this relatively small problem. :)

gettin' closer

After having to restart the code for a railsish controller dispatch.cgi equivalent for GAE (3 hard drive crashes in as many months? Really? C'mon...), I've managed to get something just about working on the dev server. The hard part is figuring out what python calls stuff, and keeping what exactly "self" is straight.

update: and nevermind... got it. \o/ Will post the hack later on. I really wish python wouldn't just pass around instances of self implicitly. :(

from google.appengine.api import users dilema

App engine comes with a library to handle user authentication off of Google's gmail servers. The idea is that anyone with a valid gmail account would instantly get access to your application, and you don't have to sweat the details of session management, password recovery, setting up CAPTCHAs and filtering out spam accounts, or any of that truly annoying stuff.

Authorization is handled through an admin console for your application. You can specify which libraries/urls require different levels of access (choices are "none", "login", or "admin") and help protect different parts of the site. Pretty simple, and pretty flexible.

There are a couple of hitches in the plan, though. First off, there's no unique identifier for a user account other than the email address. The doco claims they're mulling solutions, but nothing appears to be promised or hinted at (note to googledudes: gmail auth is a good starting point, add in support for creating and managing personal certs for the win). Second problem is that there's recently been news that spammers have found a way to beat the audio CAPTCHAs google is using and thus have been establishing spam accounts with it like it's the new hotmail or something.

A third problem really isn't that huge of a problem, but it is something to keep in mind: the standalone webserver in the SDK merely checks for the existence of a gmail account.. it doesn't do any password validation. Worse, you can give it a non-google email address and it just uses that. The problem here is that kind of nerfs the idea of releasing the source code for a web app and allowing people to run their own standalone instances of it on their own hardware.

One solution to all of this is to simply use your own user authentication and authorization system and clip out google.appengine.api.users from the equation. But now you've got the hassle of session management again, only this time no database to use to solve the problem (the BigTable datastore *could* be used here, but you wouldn't want to do it because writes are much more expensive than to a traditional database making ill-suited for temporary data). You could stand up a server somewhere else, but now you've got the cost and complexity you were trying to avoid by using GAE in the first place.

Using something like Google Gears and allowing users to have offline access to your app is one possible solution, but offline support isn't the same thing as owning your own instance of an application.

For the ideas I've got and that I'm monkey around with, this isn't really a deal breaker, but it does limit options for future projects.

Next GAE whine session: how having multiple places to handle URL routing can cause headaches. :)

sorry, I don't see the lock-in

One of the big complaints about google's App Engine was that they were trying to induce some sort of vendor lock-in by requiring the use of their python libs. After having stumbled through the getting started guide, I don't see what the foundation for that complaint is.

The way this works is that python has something called the WSCGI (google around for the spec for more info). This basically allows you to route web server requests to different portions of your python code. It's kind of like having "dispatch.cgi" embedded into Apache for a Rails application. From a programming standpoint, you simply route URls to functions, and since WSCGI is a python community standard it's the same thing that stuff like Django uses. Other than support for BigTable (which I suspect can be ORM'd out of the way) and gmail account authorization (which you can sidestep if you want to do something like run your own LDAP service on a remote server), there's not a whole lot in there that's trying to pin you down to google.

The only thing I see that's going to trip up the rails and php folks is the lack of anything similar to WSCGI in those communities.

in like flynn

There goes my free time. :)

Only drawback seems to be that appengine is tied to my gmail account, so I can't share access with other folks. I think. Haven't read any docs yet, but will be checking it out later on tonight.