Google Calendar and Atom problems
simon at thegestalt.org
Sat May 6 19:13:25 BST 2006
On Sat, May 06, 2006 at 12:37:05PM +0100, Paul Makepeace said:
> Patches welcome!
Sure ... if you'll just give me access to the Google Code base then I'll
Having stuck around on the GData list the API appears to be ridden with
bugs. But the Google guys seem to be quite responsive so hopefully it
will sort itself out.
Interestingly enough my code seems to be far more advanced than any
other bindings available. Including the official Google Java and C#
ones. Go figure.
If you do want some feedback here's some stuff I wrote to $elsewhere
"As part of my ongoing effort to subsume all Calendar activity in the
Perl world I knocked up a Perl interface to Google's new calendar api.
It wasn't too painful - just a couple of things bit me on the arse.
Trying to beat XML::Atom into doing the namespaces how I wanted was a
bit painful and the return error codes from Google's RESTful API are
less than helpful. Two examples ...
When first trying to add an entry it kept return 200 OK rather than 201
Entry Added which confused the hell out of me. Eventually I figured out
that it was because of their slightly odd session system. You first POST
to their servers and get a 302 Temporarily Moved with a new session id
in the headers. You're then supposed to redirect to that.
I mistakenly thought that LWP::UserAgent would do that for me but it
appears it wasn't keeping all the necessary data around and so the add
was failing. But failing with a success code (just not the right one).
I'm sure there's a good reason as to why but ...
So I got that working with some copy and pasted XML and tried to create
my own XML using XML::Simple (I'd given up on XML::Atom::Entry
temporarily). Entries were being created but they didn't have any of my
data in. More head scratching and more cups of tea dn I realised that I
was using <event> rather than <entry> tags. So why was it accepting it.
Why was it not throwing a 500 error or whatever like I'd seen it do
before. And for that matter why not some more debug information in the
reponse body. *seethe*
So I had everything working in a hacky sort of way and decided to move
everything over to nice, sane Net::Google::Calendar::Entry objects which
were sub-classes of XML::Atom::Entry. All seemed to be going well - add,
list and delete all worked fine. But update started to get a 404 Not
First I checked my update code but that hadn't changed since it worked
(and checking out a previous revision confirmed that). Eventually I
realised that I hadn't yet put any start and end times in. Adding them
in made everything work again. Graaagaah! Why let me add (and provide a
default start and end time) and delete but not update? And why a
fricking 404 Not Found? HOW IS THAT HELPFUL? HULK SMASH!
One thing I hated about the API was this whole magic url AND username
and password AND session-id hoop jumping dance. It's not quite as bad as
the insane Flickr authetication dance and the API does appear to at
least be better in general than that particular monstrosity but I'm
beginning to wonder if all Web Services APIs suck by nature rather than
Still, it all seems to be working now - a _devel version is up on CPAN
and I'll add some more functionality later (like recurring events, OH
JOY! <sad smiley> <weeping smiley>)"
As it turns out I did add recurring events (which involves some sort of
weird perversion of iCalendar RFC 2445 type stuff thus mixing in two
completely different formats into one). It didn't work. It turns out
this is a known problem and that recurring events just plain old don't
Basically my issue is that the error codes it returns are completely
random. Sometimes, when something's gone wrong at Google's end you'll
get a 200 OK, a 404 NOT FOUND or a 550 SERVER ERROR.
None of these are helpful. It should probably always a 406 NOT
ACCEPTABLE and then put the error data in the HTTP response body. For
example if you send malformed Atom then, you know, tell me where in your
parser it realised it was malformed. Don't just bleat that it's
malformed (on the few times it *does* actually respond with what is
actually wrong as opposed to some random error).
More information about the london.pm