Google Synchronizer

No, I don't mean Google Sync for Firefox. While that is a worthy addition to my browser tools, answering one of my main complaints for years, it's not what this is about. Nor do I mean GDrive, which is described as an on-line drive share

This is much bigger....

If you have tried Google Spreadsheets, you may have shared my experience. I thought "hey, this is great, now those spreadsheets that I access from several computers will be handy all the time, whether or not I have Excel installed"! But on trying it out, I found some issues. Granted, this is an early beta, but I believe the snags will persist unless Google adds a much needed feature - desktop file synchronization.

Here's what goes wrong:
You upload your Excel file to Google Spreadsheets and go about editing it on-line. You make some edits, save them, and access it from another machine. Great you think.
A little later, you go to access the file and find that it's not accessible. Network's down or somesuch. You now panic and return to your local copy which is by now several edits out of date. You curse and re-enter your edits, promising that your local copy will be your "real" copy and that the on-line copies will only be there for convenience. You never update the on-line copies and return to your original method of local-only editing.

How to make it really work:
Google is really close. With GMail, they made a killer app that totally replaced local email programs for me. In order to do the same for Google Spreadsheets, and future apps of this ilk, wha they need to do is make the user experience transparent. We are creatures of habit. If I've been editing an Excel file on one machine for years, chances are, I'm going to keep doing so.

However, I want the convenience of accessing my spreadsheet anywhere. Currently, I must manually upload the spreadsheet any time I make an edit locally and download it back if I edit it on-line. This is a horribly inefficient and dangerous operation, much better suited for an automated system of synchronization.

Enter Google Synchronizer. GSync, as I'll call it, is an OS patch that intercepts file i/o requests and does a very fast check to see if a given file is tagged as having an on-line shadow. If it does, GSync activates a synchronizer program that brings the files into proper sync, allowing local edits. This could be Spreadsheets, word processing documents, money manager files, images, whatever.

Clearly, this is a non-trivial application. It involves numerous file formats, file locking, multiple simultaneous editing, etc. However, it is one of those apps that once people use it, they will wonder how they lived without it.

In order to be successful, it has to be implemeneted so as to have minimal impact on the user experience. File checks cannot add measureable OS overhead. There shouldn't be more than a check in the file header (like the archive, r/o etc. bits).

Likewise, once GSync has determined a file needs to sync, it cannot take forever checking an on-line database. What if your connection is down or bogged? People don't like to wait! As such, the file must load up and display as normal. A background thread can check for on-line version(s) and report to the main app when it can. If no connection is available, it will just warn the user of that fact and choose a course of action. They could "edit anyway", knowing that the file might be newer on-line. Or "view only", if they just wanted to browse the file for some info. Or, "try again", just in case they forgot to activate their connection or there was some moentary glitch.

File synchronization should transfer the minimum amount of information required to get the job done. If a megabyte spreadsheet is modified, chances are, only a limited number of cells were actually edited. GSync would only send a change log to the on-line handler to incorporate the changes. This would also facilitate multi-user editing of the file as it would make synchronization nearly trivial on the server side.

Some files could be considerably more difficult. For example, if you were editing a sync'd image in Photoshop, all the pixels would be changing. However, one could still pass the change log on to the server and have the server make the appropriate changes to the on-line file. The downside is that the server then has to handle the burden of millions of users' data manipulation. There will need to be some arbitration process which will decide whether it makes more sense to just re-upload the modified file or integrate the changes on the server side.

Note in the above example, I used Photoshop as the sample app, not Picasa. The key to GSync's success is to allow people to use their old familiar apps as well as Google supplied apps to edit their files. This requires integration with third party software.

While initially this will be a big problem, third parties will soon learn the power of supporting this functionality. Google produces useful, but limited, applications. Picasa is not going to replace Photoshop for hard core image editors. It's a very useful tool, but limited. Files anywhere is such a powerful feature, that once users get a taste of it, they'll demand it in all their apps. Supporting an open GSync standard will allow interoperability, reduce R&D time, and give vendors a step up on their competition.

GSync is the next evolution of the personal computing phenomenon.