Last April, we demoed some of the structured blogging capabilities of BlogMatrix. Part of the demo involved posting an event and having it show up in Google Calendar. We've recently decided to make that code part of the standard "base" installation under a system called continuous export -- whenever you post something, it will show up on other systems as appropiate.

Anyway, I couldn't get it to work so I contacted the Google Calendar Data API support group where a gentleman named Ryan Boyd helped me out. I didn't quite believe his last answer so I decided make a standalone test case that could be safely shared. Of course, after I finished writing it the test case worked perfectly so I ported back that test case code and everything's working just fine.

As a public service, I've included the test case code here. If you're trying to do PUT/POST using Python's urllib2, need to login to Google Calendar, or whatever, this code is well documented internally, is easy to follow, and it works.

This will demo quite nicely -- you can go to upcoming or any other hCalendar supporting tool, import the event and have it published on your Google Calendar. Neat and useful.

Outstanding items:

• making sure when an item is deleted in BlogMatrix, it's deleted on Google Calendar
• implementing Google Account Authentication
• make Google Calendar update (in the user's browser) when the item is added. Currently, one has to press the browser's refresh button which is suboptimal

If you're researching Google's various APIs, you're bound to come across something called the "Google Data API" aka GData. It describes itself as:

The Google data APIs ("GData" for short) provide a simple standard protocol for reading and writing data on the web. GData combines common XML-based syndication formats (Atom and RSS) with a feed-publishing system based on the Atom publishing protocol, plus some extensions for handling queries.

It's a lot more than a protocol though. It also defines a data model ("kinds") for populating commonly used elements. Here's some of the types:

• gd:comments
• gd:contactSection
• gd:email
• gd:entryLink
• gd:feedLink
• gd:geoPt
• gd:im
• gd:originalEvent
• gd:phoneNumber
• gd:postalAddress
• gd:rating
• gd:recurrence
• gd:recurrenceException
• gd:reminder
• gd:when
• gd:where
• gd:who

These elements have deep structure, attributes and other such things. What does it have to do with the Google Base model? Easy to answer: nothing. This is very very unfortunate and it probably a good sign as any that Google's becoming a pretty big company, like IBM or Microsoft.

What use does Google have for GData? It's main purpose at this time is to allow outside to tools to populate Google Calendar. We can only hope this will somehow be merged or made consistent with the Google Base model and API.