Wednesday, 02/26/03

Matt Gemmell's brain dump of Rendezvous projects reminded me to write this up.

A couple of weeks ago I belatedly discovered Stuart Cheshire's amazing Rendezvous talk from last year's WWDC (available with a free account at Apple's developer site). Rendezvous, for those who don't follow such things, is a deeply clever way to make sure computer users never have to think about IP addresses for devices on their local networks, and to make sure devices can find each other without configuration -- so you can plug in a new printer, or fire up a new web server, and network-wide it just pops up in a picklist, without hassle.

I was already a fan of Rendezvous, and had a grasp of the fundamentals, but Cheshire's talk really sews up why they did things the way they did, and I came to understand at a deeper level why it's such gorgeous technology. Since then I've been thinking about ways to put it to use.

For a long time I've pondered ways to exchange data that won't easily swim in the filesystem, like sychronizing clipboards, or browser bookmarks, or keychains between OS X machines. Writing a pleasant synchronizer is manageable, but it can only do its work once it has the data from the "target" computer. The labor of exporting and transferring the remote data to be synchronized drags down the process, except in cases like the clipboard, where it effectively is the process.

That transport hassle is exactly the labor that Rendezvous whacks. So, duly inspired, I started picturing a Rendezvous-powered middleman app, with only enough UI to put itself out on the network, spot other copies of itself, and open point-to-point connections with the permission of the target machine.

I'm thinking that once a connection is established between two machines, it's placed at the disposal of any app that wants to talk to something on the remote end. Requests and replies are made to the middleman running on your own Mac with Apple Events, transferred to the remote middleman as XML, and turned back into AEs targeted by the sender. XML also encapsulates data unsuited for representation as an AE.

With the network code out of the way, my hypothetical Address Book synchronizer can just concern itself with synchronizing Address Book data. To speak across a network, it only has to learn a couple of AppleEvents: one to package up the local machine's Address Book data for transmission upon demand, and one to blindly query a middleman app: "You've got a connection? Good, ask the Address Book synchronizer on the other side to send me its data", from which it gets XML-formatted data to process.

Because middleman communication, on both sides, is performed with Apple Events, middleman client tools could even be written in AppleScript.

True, it's possible to send Apple Events across a network by themselves, which gets an application most of the way there without needing a middleman. Remote AEs are a security free-for-all, though, and unless you incorporate a lot of Rendezvous in each app, you'd wind up scrabbling around for the IP addresses of the remote machines. At this point, I'm still thinking my scheme sounds way better.

It felt right to keep refining the idea, and after not very long, I realized I'd refined it into something that already existed. And that's the story of how I invented Web Services, about ten days ago.

The lesson I draw from this is that it's still too hard to build SOAP/XML-RPC servers, especially if they have to work with Apache (and I say this as a qualified Apache tinkerer).

Rendezvous will yet have a role to play when that day comes, in allowing people to refer to computers on the local network by names instead of numbers. But its killer app is still hiding somewhere. The technology can survive, even thrive, as no more than a way to reduce configuration for printers and networked games, but it's too pretty for that to be all. I haven't figured it out. 12:20PM «

Bits pushed by Movable Type