I managed to get to the SF Google I/O conference today. I will admit that this is rather interesting.
I missed the Guice presentation in favor of an overview of the Google App APIs and application integration. The latter started so late perhaps I made the wrong choice.
The App APIs look like an easy reach for Sakai. I'll have to go to the authentication session later today, and then look at provisioning.
Now I'm attending a "get google apps running on your mac foo" workshop. Let's see how that goes. My Python is a bit rusty.
( later ) That was too easy. there were some typos in the presentation ( all of them so far ) and the hands on code was missing some python page template content ( ! ) but it really works nicely. I still want an IDE for setting breakpoints.
ach this is all HTTP. too bad. it would have to use anonomized IDs on the google side with a resolution table in the secure side. no threads. no C using Python APIs.
-- later, some notes on the "inside the app datastore" chat.
Google app datastore: bigtable. New term for me: "sharded data." This refers to splitting data across several servers. I've done that but I didn't know the name.
this datastore is a big array. a set of arrays, when you consider the indexes. lots of scanning; they must have a special filesystem at work here. This thing just hammers across the array.
So one can build all these tables. and their indexes. and composite indexes. The presenter is really dancing around how much all this costs the developer. the presenter sez "Im not a PM, and we don't want to charge for composite indexes because that will cause you the app developer to do all sorts of crazy things."
presentation is straightforward. slides look like LATEX.
interesting bit on expando rows; you won't find records for those expandos which lack an attribute used in a compound key. suggestion; reflect across the expando before storing it. (?) I must of missed something there, I guess your app wld keep track of what new attributes had been added in the past and force those attributes on new records? hmm.
transactions - timestamp journals. related things are bundled into "entity groups"
-- later, "Auth to Google APIs"
ClientLogin: lives on app on hardware owned by the user. does deal with users original creds. like cell phone, cant' easily redirect. token expires after a while. one HTTPS POST, U/Pwd, service name ( which Google API) get token back from google. CAPTCHA may be involved. Auth token returned, stuff it into your Authorization header. Nothing prevents a web site from using this approach.
AuthSub: user redirect to google, they auth w/ creds, and are redirected back to you. Tokens can be long-lived. Two redirects; one over and then back. provide an endpoint for the callback. Can be tightly scoped or wide; one token for calendar, contacts & docs. ( yer token is a one time token which is easily upgraded to a long lived session )
Secure AuthSub: so far token is in clear text. to get past that a domain may be registered with Google. during registration provide a public key. it will be used by google to encrypt the token. there is an interesting handshake between you and google where they confirm you administer the domain - for example a special .html file you publish w/in your domain containing data generated during the registration process. cool.
OAuth: "Upcoming standard which looks like AuthSub." Registration, HTTPS req for scoped token, redirects back and forth. finally sign all following requests.
lots of client libraries. hmm, perhaps not; java 1.5 and X. available now.