Sidingsound

Last October, I posted about a small problem which I was trying to work out: how to synchronise the calendars on our Mac and my Nokia N95 mobile phone, with Google Calendar.

Four months on, and I’m sorry to say I haven’t made much progress in the interim. To recap, these are the essentials of the setup which existed prior to last October:

• The N95 calendar synced “over the air” with Google Calendar via the GooSync service.
• The Mac calendar synced with the N95 via iSync on Mac OS X.
• The Mac can also update Google Calendar directly via iCal, thanks to GC’s CalDAV interface.

You may have worked out that Google Calendar acts here as the de facto “master” calendar, i.e. the primary copy of the calendar data. In this setup, the Mac doesn’t have a “local” copy of this data (it connects to Google’s server and displays what’s there), whilst the N95 does have its own copy of the data, but still treats Google as the “master” version.

This arrangement worked fine until last October, when GooSync ended its free service level, in favour of “GooSync Lite” (£5.99 per year). I haven’t renewed my subscription to date, as I’ve been prevaricating on what would be the best option—a lifetime subscription to GooSync Premium is £40, with a fair number of additional features, so that might be worth consideration. (The same service costs £20 for 12 months, and £30 for two years; how likely is it that GooSync might disappear within that time?)

So, at present, I can access Google Calendar via the Web, or via CalDAV (using either iCal on our Mac, or Mozilla Thunderbird (via the Lightning calendar add-on) on my Linux-powered Asus Eee 701 netbook). If I want my calendar synced to the N95, at present I would have to sync the phone with the Mac rather than Google; this is all well and good, but what if I am away from home and therefore unable to access the Mac?

I am also unsure whether iSync will transfer calendar items which aren’t located in the Mac’s own iCal database—i.e. because they’re on Google’s servers instead. For me, this is a wider issue: the Mac and netbook can only display the calendar if they have Internet access (more of a problem for the netbook, as the Mac stays at home). Therefore, I would like to find out whether it’s possible to sync the Mac and netbook calendars with Google (i.e. create synchronised copies on these machines of the events on Google), so that the events can be viewed and interacted with when the machines are offline.

I think I have a few options at this stage:

• “Admit defeat”, and cough up for a GooSync subscription. Otherwise known as the “path of least resistance”, at least this would sort out the N95/Google sync issue. If there are SyncML-compatible clients for Mac and Linux, I suspect GooSync Premium might also solve the “local copies on Mac and netbook” issue above, as GP allows up to four “devices” to use the service; this may require an email to GooSync to clarify.
• Sync the N95 with the Mac (and/or netbook) instead of Google. This would rely on a few “ducks in a row”: for one, clarifying whether iSync on the Mac needs the calendar items to be present in the Mac’s iCal database first. There is apromising-looking “one ring to rule them all” syncing utility for the Linux GNOME desktop—Conduit—which looks like it might be able to act as the go-between for Google, the netbook and the N95, but so far it appears that mobile phones are not yet supported explicitly (no doubt that will follow).
• Some combination of the above—e.g. GooSync for the N95, and other methods for the Mac and netbook.

So, the saga continues—just hope I can come up with a suitable solution before that vein in my head goes “pop”…

Many of you who use Google’s various services (Calendar, Reader, Docs, etc.) wll be aware that you can access them over a secure (SSL or “https://”) connection. It’s often a good idea—in fact, I believe that GMail can’t be accessed any other way—and it’s usually quite easy to achieve (often, simply changing the ‘http://’ on the front of the URL to ‘https://’ is enough. I try and use the SSL addresses as a matter of course—certainly when I’m out of the house, and definitely if I’m using public WiFi—as you can never be sure if someone else in range is ’sniffing’ the network traffic.

Recently, however, I’ve been frustrated by my attempts to try and access some Google services via ‘https://’, using my Linux-powered Asus Eee 701 ‘netbook’. Whenever I tried, I would be redirected to the non-secure version of the page, or even the default Google/iGoogle home page—really not what you want, especially if on a public network.

I was stumped by this: was it a problem with the Linux Firefox? The particular version of Firefox I was using at the time (v3.0.1—I have since upgraded)? Something even more sinister…?

Um, no, actually—I have just worked it out, and I really should have thought of it before. Basically, Google usually allows you to access specific services of theirs, via two URL ‘patterns’. For instance, if you want Google Calendar, you can use either www.google.com/calendar or calendar.google.com—either will do.

Or at least, this is the case if you only want to access the non-secure (http://) pages. If you’re looking for the secure (https://) version, you can only use the “www.google.com/[service]” URL pattern—try using “https://[service].google.com”, and you’ll be redirected straight to the insecure pages, with no warning that this is going to occur.

So, if you want to ensure (as far as possible) that you will get through to an encrypted Google service, make sure that you enter the URL in the format https://www.google.com/calendar/ (or whichever service you want), and all should be well. (And while I think of it: at time of writing, I believe that only the “google.com” domain enables “https://” connections, so “google.co.uk” and other national domains won’t give you a secure link either.)

Hope this helps someone else

The BBC technology correspondent Rory Cellan-Jones, has written a post for the BBC’s dot.life blog, titled “Who will ride Google’s Wave?“. Along with ZDNet UK’s “first look” at Google’s new baby, Rory’s article may well be the first one I’ve encountered which (IMHO) actually explains in simple yet non-patronising terms, what Google Wave is/does, and why it should be of any interest to the likes of yours truly.

And better still, now I’ve read it (and watched some of Google’s own demo video—embedded below), I can say that yes, I am interested.

ZDNet’s article describes Google Wave as “a cross between IM and a wiki”, and that’s as good a place as any to start. Google themselves put it a bit more prosaically:

Google Wave is an online tool for real-time communication and collaboration. A wave can be both a conversation and a document where people can discuss and work together using richly formatted text, photos, videos, maps, and more.

I’m only judging from what I’ve read (and Google’s demo video), but assuming this is all what’s being worked on: imagine a wiki (say, Wikipedia), but a wiki which evolves, sprouts extra text, images, videos, embedded maps, and so on and so forth… all in real time as you are looking at the page. Text can be seen being entered, conversation threads appearing and developing as you watch… yes, basically like “a cross between IM and a wiki”, as ZDNet said. And all this is not a program you install on your computer—it takes place inside your Web browser (well, unless you’re using Internet Explorer, which as the ZDNet preview points out, isn’t quite up to the task).

At time of writing, Wave is a “limited beta”, meaning that you can only use it if you are one of a very select band who found the Golden Tickets inside the Wonka bars… or if you live in the real world, if you have been lucky enough to receive an invitation. This is apparently with good reason—Wave is reputed to be still rather buggy and unpredictable—but I have “signed up” for notification when the service is opened up to the wider Web in due course.

I hope Google Wave fulfils the promise it seems to be showing here, as I can think of all sorts of uses which it could be put to (real-time collaboration between workers, researchers, etc.; the “next level” of Web forums; another tool for customer service; and so on). I can’t help thinking that this is a first stab at what the Web could evolve towards over the next decade or so… or it could turn out to be a fascinating experiment which leads nowhere.

Only time will tell, but I’ll be keeping an eye on this one to see where it goes.