Google ditched its browser sync plug-in for Firefox a year ago, but the idea is resurfacing in Chrome in a way that makes me think of possibilities the technology could hold for Chrome OS.

The company is preparing to build a system to synchronize bookmarks across different versions of Chrome, Google's Tim Steele said in a mailing list posting on Friday. Google envisions extending the feature to other data types, including passwords, Steele and fellow programmer Idan Avraham said in a follow-up posting.

"We wanted to focus on bookmarks and get it right first before we think about other data types. We chose bookmarks both because they are generally the most important to users, but also because they are the hardest data type to sync," Avraham said.

Synchronizing bookmarks is a fairly basic concept. The Xmarks plug-in, formerly called Foxmarks, has solved the issue for years on Firefox, so users could move from a work computer to a home computer and still have their saved Web addresses intact. Google had its own though now extinct option, and now Mozilla itself is building a plug-in called Weave that synchronizes bookmarks, passwords, tabs, and other information. Yahoo's Delicious service has been available for years for people to store bookmarks centrally in the cloud and to share them with contacts as well.

So it's no surprise Google feels compelled to add bookmark sync to Chrome--especially given that the company plans to use a person's Google Account to save the list. Google likes the idea of storing the state of people's applications in the cloud, even if they're relying on a local computer's horsepower to run.

Bookmark sync will arrive gradually; initially there won't be a way to sync bookmarks using Google Bookmarks service that can be used directly or through Google's browser toolbar, Steele said in another message. "For the first release, we've just focused on getting sync to work between Chrome instances," Steele said.

The synchronization feature may be a basic utility, but Google sees it as much more than just updating a list of links. In fact, it chose to use Google's own high-powered Google Talk infrastructure to handle the service, the design document states. Essentially, that means browsers only need to listen for broadcasts when a change occurs rather than frequently check in for them:

To make this sync infrastructure scale to millions of users, we decided to leverage existing XMPP-based Google Talk servers to give us "push" semantics, rather than only depending on periodically polling for updates. This means when a change occurs on one Google Chrome client, a part of the infrastructure effectively sends a tiny XMPP message, like a chat message, to other actively connected clients telling them to sync.

To put that gain into perspective, consider a three-minute polling interval. Three minutes is far from real time, or "immediately" as our goal was stated. But already, at the very least, every three minutes every client needs to ask the server if anything changed. Even with just one thousand users, we're already talking about a server having to handle a poll request every 0.18 seconds on average (or roughly 5.6 queries per second). And that's just when nothing is happening! Using XMPP pushes, the sync servers don't need to waste cycles for no reason.

There are other synchronization possibilities for the browser. Peter Kasting, another Chrome programmer, offered his personal wish list: "I'm more interested in history/visited link/omnibox syncing than bookmarks," he said in a posting. Synchronizing those elements would mean one instance of Chrome would behave more like another, for example being able to retrieve more easily the address of a Web site that a user already visited on another computer.

But the high-powered infrastructure raises some interesting possibilities in the long run. Who needs a hyper-responsive utility just for synchronizing bookmarks or browser history lists? When was the last time you were saving bookmarks so fast that there was a danger multiple updates would run afoul of each other?

The thought I had is that perhaps Chrome OS could benefit from a high-speed message-passing interface. After all, on Chrome OS, Chrome gets the glamorous job of running the Web applications, with the underlying Linux operating system handling more mundane hardware duties.

Perhaps there are situations in which sending lots of XMPP messages could help Google-hosted applications stay in tune with each other. Google Wave, which uses XMPP already to power its group-chat abilities, is one example that springs to mind. Today that's a Web application that doesn't need a browser to handle that lower-level interaction, but might it work better if it were built in? Gmail can use IMAP to keep the same inbox synchronized among different computers, but maybe this would be easier and faster?

Then again, as Freud said, sometimes a train is just a train.