Google Calendar and Atom problems

[Simon Wistow]

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 
patch it.

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 
Found. WTF?

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 
bad implementation.

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 
work.

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).

Simon