My largest problem was that I didn’t want any single location to be the absolute truth in terms of knowledge, especially when it came to choosing where to edit.  As an example, I dont’ have to have to go to google calendar to edit, just because my iCal can only *read* from there, or vice-versa.  So enter GCALDaemon, a Java (I know) app which can run on linux, mac, and more and allow bi-directional work between my gcal, and ical, kontact, and more.  It works quite well, except the direction don’t apply for the current Leopard release of OSX.  The main difference is in the location of where iCal stores its information, which is now in:

~/Library/Calendars/<Unique-id>.calendar/Events/*.ics

Which just happens to be the data you need for the config file, instead of the location they originally suggest.  Also of concern was that by default, my google apps calendar wouldnt’ give me a “private” link, but I just had to munge the url of the public ics file with a s/public/private/ and it worked.  I now have my google calendars syncing bi-directionally with my laptop and desktop.

I haven’t tried yet, but it also has a tool for getting an LDAP access to your google contacts, which will be nice.

And for those who want to use Mail.app (my wife) here is a hint for getting your default folders to sync correctly: Map Gmail Folders to Mail.app Default Folders

And for those that don’t know.  Why IMAP?  IMAP is the protocol that lets you view your mail on the server, instead of just downloading a copy.  So if you delete an email, it’s deleted on the server.  If you move it to a folder, it is on the server also.  So you can use whatever email client you want on your personal box, and still see your changes when you view it in the web interface.