Want A Date? We All Cal With ICal (Thanks to Scripting News for the link)Whats interesting about this (to me) is that Apple went ahead and and said, "lets use a standard format (vCal) for this thing, and just upload it to the server. Lets let each individual machine sort out what to do with the information containted in a calendar."Contrast this with Microsofts .NET MY Web Services initiative, where calendar sharing was to be one of their for pay features. MS was claiming that federation, or the ability to have more than one host for the information, was part of the plan from the beginning. But because they owned the xml structure and were tightly controlling how the whole business worked, no-one on the outside woud have a leg up on how to implement a federated server. (I suppose you could buy the federated server package from MS?)In contrast, Apple went with two established standards (vCal & DAV) and didn't try to own the file format.If there is information that must be shared, the file format should be in the public domain and subjected to peer review. Don't go crazy with that, since you've got to ship sometime and mistakes can be fixed (as long as you always leave one bit in a bit field to mean: more data coming!)Note that vCal isn't XML. It doesn't need to be. XML and vCal are just file formats. [Steve Zellers' Radio Weblog]vCal is a decent format. I really like the concept of iCal as a subscriber/client of multiple HTTP served calendars. The day iCal was announced, I threw together a 24Tix calendar of upcoming shows as a Python Script - so it's dynamically updated with new shows as they're put in the system. It took a few minutes, basically of reverse engineering an iCal export in vCal format, and then tracking down the vCal spec to see what else I could/should do with the system. As a result, we have this calendar (subscribe), complete with venue information.There's still one missing piece - I still want one personal calendar, even across three machines (workstation, home iMac, iBook). I guess this is where calendar servers come in to play, and maybe it is what .NET My Services could offer. At MWNY, Steve Jobs hinted that the upcoming iSync application could sync multiple Macintoshes over .Mac. Just the notion of this one feature is enough for me to pay for .Mac (which I did do, just a couple of days ago). There's part of me that thinks that the Backup software offered as part of .Mac (or usable separately) could be used to get a cheap version of this now. But I'm a little leary. And I'm a little leary of using Backup because, again, I have three machines. Two of which are in active use. And as I learned during my recent iMac clean re-install, Mac OS X is very easy to restore to if you just preserve some aspects of your home directory (the layered architecture of how Mac OS X handles preferences is a delight compared to the overstuffed system folder of the classic Mac OS). Will Backup let me back up both machines to the same account without trampling on each other? I guess I'll find out sooner or later.So, I still have a dream of being able to easily maintain one calendar, one address book and even one quicken file across multiple machines. I'd love to be able to sync Quicken (even if it just meant "copy the file") to my iBook when traveling (I use Pocket Quicken on my palm, and love it, but sometimes I've wanted to have the full package there (primarily before Pocket Quicken 2.0)) and a couple of OmniOutliner outlines as well. I want to sync up from my iMac while brushing my teeth before heading to the office, and sync down to my G4 Workstation when I get there. And then do the same thing before I leave the office.This is the service that I want - especially if conduits can be made to do it intelligently, like Pocket Quicken - but between Macs instead of a Mac and a Palm. If iSync can deliver on this, than the $50 I shelled out for .Mac will be more than worth it.