Google Apps for Domains Part III

by R.I. Pienaar | Apr 8, 2007 | Front Page

This is part 3 of my series of posts on the general usability of Google Apps for Domains as a hosting service for email. This one really speaks for itself so I’ll keep it short.

Google Apps for Domains Part II

by R.I. Pienaar | Apr 2, 2007 | Front Page

This is the 2nd in a series of posts about Google Apps for Domains, I’ve been evaluating it for a while. Today I’ll focus a bit on the XML feeds that Google Calendar outputs as a means of integrating it into other applications.

It basically provides 2 types of XML – a private and a public one. The public one only works if you share the cal publicly and the other is for your own use to pull into apps of your own. Each calendar should have a private one.

This sounds very interesting, so what’s the problem? Well there are some inconsistencies. On my two domains, the one has private URLs on the main calendar the other doesn’t have the option at all. So this means my primary calendar doesn’t have a XML feed unless I share it publicly.

GCal also has a feature that mails you a short daily agenda, much like what you see if you hit the Agenda button. Problem is the agenda mail function ONLY reads from your primary calendar, it does not include events from any subscribed calendars etc. This means that one of the biggest selling points of Google for Domains is crippled, if you share calendars you can’t use them even in the rudimentary tools provided.

I can’t use my primary private calendar with XML feeds, and I can only get events mailed from the primary calendar. Why is this a problem? I want to use the shared calendars with people I work with, that’s one of the major reasons to use Apps for Domains.

On my iCal calendars I had a RSS feed that I’d pull into some perl code to generate agendas. I resigned myself to the fact that I’d need to write one myself again now for GCal and wanted to use the XML feeds. I can’t pull events into my primary calendar – it doesn’t have private feeds – so I had to create a new cal and use that – completely invalidating the in UI agenda function. I also can’t delete the primary function, the option is grey’d out.

Back to the feeds, by default the data you’ll get in a feed looks like this for recurring events:

<?xml version='1.0' encoding='UTF-8'?>
<entry xmlns='http://www.w3.org/2005/Atom'
xmlns:gd='http://schemas.google.com/g/2005'
xmlns:gCal='http://schemas.google.com/gCal/2005'>
<id>removed</id>
<published>2006-09-04T18:45:41.000Z</published>
<updated>2007-03-15T23:50:18.000Z</updated>
<category scheme='http://schemas.google.com/g/2005#kind'
term='http://schemas.google.com/g/2005#event'></category>
<title type='text'>Cleaners</title>
<summary type='html'>Recurring Event<br>
First start: 2006-09-01 11:30:00 BST <br>
Duration: 3600   <br>
Who: Shared Calendar  <br>
Event Status:     tentative</summary>
<content type='text'>Recurring Event<br>
First start: 2006-09-01 11:30:00 BST <br>
Duration: 3600   <br>
Who: Shared Calendar  <br>
Event Status:     tentative</content>
<link rel='alternate' type='text/html' href='removed' title='alternate'>
</link>
<link rel='self' type='application/atom+xml' href='removed'>
</link>
<author>
<name>R.I. Pienaar</name>
<email>rip@removed</email>
</author>
<gCal:sendEventNotifications value='true'></gCal:sendEventNotifications>
</entry>

Have a good look at that, this is the default feed output, it shows you details for a recurring event – when it was first created and how long it runs for. There is not enough information here for a human to actually figure out when this event is for, they do not give you any information about the schedule, this event may recur once a year, once a day, once a month you just don’t have any idea. You’ll see later that they have all the ability already to make this useful and user friendly, they just didn’t bother.

The devs in the Google Support Groups say the default feed is for ease of reading by a human and not for machines, for machines you need to use the full feed query format . This lets you do all sorts of good queries for feeds, date ranges and all sorts of things.

Not only is the default feed not machine friendly, no human can figure out what a recurring event is, when it runs etc, as a data feed the default GCal feed is completely useless to everyone.

Using the full feed I now have a daily mail that I have to schedule on my own server to produce a daily agenda, something like this:

Things to do TODAY - Monday, 02 April 2007
No events.
Things to do TOMORROW - Tuesday, 03 April 2007
Test Event
Things to do next 7 days:
Friday Cleaners
Friday Good Friday
Saturday Rebecca Birthday Party
Monday Easter Monday

I had to write this myself using perl and had to go and do this using the full feeds, interestingly enough the full feed has options to expand the recurring events into a single entry, so for instance my Cleaners entry in the agenda above is the same recurring event from the XML earlier. So clearly their backend has the ability to turn the nasty useless recurring event format into something totally human readable and useful, they just chose not to make the default feeds a useful feature.

The calendar has a lot of other questionable features and limitations, it really is a load of compromises, bugs and half baked features cobbled together in something that does not really work as a proper shared calendar environment like a paying customer would expect. And these limitations is not limited to the free versions, they are exactly the same in the paying version. I’d say anyone serious about shared calendar apps or about 3rd party integration should really give GCal and Apps for Domains a miss.

Google Apps for Domains part I

by R.I. Pienaar | Mar 30, 2007 | Front Page

A few of my clients have indicated an interest in moving their mail to Google Apps for Domains, for those living under rocks it’s basically GMail hosted on your own domain. It combines Google Docs (Spreadsheet, Word processor), Calendar, Google Talk and a few other services into one.
So I setup a a test domain a while ago to do a proper evaluation but not against their pay version using the free service. The idea is if the free version is passable but not fatally flawed then the paid version should be fine.
It’s been painful to say the least. First I mistakenly set up a domain that I shouldn’t have since it was already in use and I couldn’t migrate it, my mistake. I figured I’ll be nice and let them know of this and get them to shut it down – a useful exercise since if you do decide to move to them and later want to move away, what you don’t want is your domain in limbo on the Google servers with possible mail routing from inside Google to it and not your real domain.
So first I try and change the primary domain name, can’t, you can add other domains, but it’s impossible to change the primary domain. So I contact them and ask them to shut it down. They contacted me saying no problem, all I need is to send them the PIN code I can get inside the control panel. The thing with these PINs are they keep changing often, so an ex staff member for example can’t claim to be working for you since the PIN won’t be valid anymore, nice feature.
Problem is it takes them longer to respond to support requests than PINs are valid for. So the process goes as follows:

1. Ask to close domain
2. Get asked for the PIN, supply the PIN
3. Support people checks your PIN, it’s not valid anymore because they took too long to check it.
4. Get asked for PIN, supply the PIN
5. Go back to 3

That’s just pathetic. Combine this with shoddy level of service, there has been several well published extended downtimes in the first month alone and other weird outages. Yesterday for example I couldn’t access any attachments since some automated bot decided I did something wrong and returned a “Lockdown in sector 6!” error, amazingly descriptive that is, needless to say I never heard from support on this issue.
There are other deep rooted issues as well like with the feeds out of calendars etc, but more on that later. I’ll make a few posts here over the next while with my experiences.