Googler Sheds Some Light on GCal’s future API & Feeds
"Google Calendar has launched (and there was much rejoicing). It uses Atom feeds for public calendar information. I'm wondering if these have been documented somewhere".
To which Kyle responded by saying that:
"The extensions used in the Calendar feed will definitely be documented and those docs should be available soon. The Calendar Data API support (these feeds plus the ability to programmatically create, query, edit, and delete Calendar events)
isn't officially launched yet… the release is going to be slightly staggered from the main Calendar Web UI launch that happened today.
The best place to look for API info once it is available (and to send any feedback about it) will be in the Google Calendar Data API Group that has been set up for this purpose. More announcements will be made there (soon) once the full API launch happens".
On the same day, Rogers Cadenhead, revealed in his blog, workbench, that since GCal's Atom feeds have items with published dates in the future that coincide with the scheduled date of the event, a warning is sometimes triggered in the Feed Validator. Roger stresses upon the fact that these Atom feeds aren't well-suited for presentation in a reader in their current form. One solution that he's suggested is for Google to make the feeds more presentable by using the published and content elements to announce the upcoming event, since the GCal developers have added a namespace for calendar features that includes a when element for the event date.
A day later, Kyle, admitted in a comment on Roger's blog that Google is aware of the issues with the Google Calendar feeds for feed readers while also pointing those interested towards the google group. Kyle wrote:
"The atom:content element in the Calendar feeds currently contains the event description, which is sometimes blank or does not contain enough basic info (event date/time, location, etc) to make the feed reader view of the event as useful as it could be. One option we're evaluating is moving the description data to an extension element and auto-generating that contains more suitable, html-formatted aggregate info about the event. The best place to send Calendar Atom feedback is here: http://groups.google.com/group/google-calendar-help-dataap "
After looking around the newly created Google Calendar Data API group, I found the following statements that Kyle had made in response to various questions and doubts on calendar feeds which had been raised by fellow developers on the google group:
1) "We will definitely be giving the threading extensions a closer look".
2) "We're aware of some issues in this area that could make life better for feedreader users. Stay tuned as we get ready to launch, wedefinitely want to make this (syndicating events to a feed reader) work well".
"I can't go into the details prior to release, but what I can say is the basic approach used for the Calendar Data APIs will beclient-language agnostic; so it should be possible to build clients that can interact with Google Calendar Data in a variety ofprogramming languages".
So in summary fashion, we can expect the GCal API to:
1) programmatically create, query, edit, and delete Calendar events
2) it's release is going to be slightly staggered from the main Calendar Web UI launch
3) Description data will might be moved to an extension element which can be auto-generated into a suitable, html-formatted aggregate info about the event.
4) the ability to generate proper validated RSS feeds
Looks like there's going to be a tie-up of Google Reader and GCal 😉
No comments yet.