It's not unusual to see something emerging from Google's laboratories that folks in the general press fail to understand, and the company's marketing is partly to blame there. The public introduction during this morning's I/O Developers' conference of a Web programming construct called Google Wave generated headlines ranging in scope from a new competitor for Microsoft SharePoint, to a next generation social network, to a series of browser extensions for Chrome to rival the Mozilla Jetpack project, and finally to the company's evil plan to conquer and corrupt HTML 5.

Excluding the latter, it could very well be all of these items. Essentially, Wave is an architecture, and not really a very new one. It's an old solution to a very old problem: that of synchronicity in distributed applications. As database architects know better than anyone, the problem with maintaining a distributed database is that multiple users may make changes that conflict with each other, leading to disparity and multiple versions. Currently, transactional modeling solves that problem, but a more direct and simpler approach from a mathematical standpoint would be simply to translate every operation, or every change a user requests to a database -- every command from client to server -- into a figurative mathematical language so that the terms of the command take into account the changes simultaneously being ordered by all the others.

It's a simple concept on paper. Accomplishing it has been relatively impossible up to now, mainly because the speed and connectivity have not yet existed to deploy a transformational database matrix on a massive scale. But "Google" has come to mean massive scale, and now it's giving the concept a try.

Operational transformation (OT) -- a way of rewriting every transaction to take into account all the others, prior to executing it -- could lead to some very sophisticated, connective applications. One way that it works is by upsetting the typical hierarchy of database architecture. Whereas typically you might think of a database as a thing in the core to which changes happen, OT reverses the concept by generating a kind of change model that bears a striking resemblance to a Feynman state-change diagram in quantum physics. Here, the database or "document" that ends up being the beneficiary of change, is used to represent the change itself, or what the architecture calls a wavelet. It then passes through the state change diagram like a blowing piece of paper pierces through a barbed-wire fence.

"Under the basic theory of OT, a client can send operations sequentially to the server as quickly as it can. The server can do the same. This means the client and server can traverse through the state space via different OT paths to the same convergent state depending on when they receive the other parties operations," reads a Google white paper on OT. "When you have multiple clients connected to the server, every client and server pair have their own state space. One short coming of this is the server needs to carry a state space for every connected client which can be memory-intensive. In addition, this complicates the server algorithm by requiring it to convert clients' operations between state spaces."

The difficulties in implementing OT described here could be shifted entirely to the server side, on Google's end. Developers, meanwhile, can simply concentrate on getting their signals across, sending messages that trigger their systems to traverse the "state spaces," without them having to know what a state space is. So one could take the code for Google Docs, let's say, and rewrite it so that multiple users are capable of editing a document concurrently. It requires a client/server architecture with a massive server scale, but Google may be the one to pull this off.

It doesn't take a big leap of logic to take that same altered, synchronized word processor and convert it into an instant messaging app. If everyone's writing, drawing, and embedding links and images to the same file in real-time, then the document itself becomes a de facto messaging tool. Change the front end a bit -- or what open source developers call the "chrome" -- and you essentially have a better Google Chat than Google Chat, one where you can see what everyone is typing as they type it.

As Google engineer Lars Rasmussen wrote this morning, "In Google Wave you create a wave and add people to it. Everyone on your wave can use richly formatted text, photos, gadgets, and even feeds from other sources on the Web. They can insert a reply or edit the wave directly. It's concurrent rich-text editing, where you see on your screen nearly instantly what your fellow collaborators are typing in your wave. That means Google Wave is just as well suited for quick messages as for persistent content -- it allows for both collaboration and communication. You can also use 'playback' to rewind the wave and see how it evolved."

But that's just the front end, from the user's perspective -- more accurately, it's the first test application of the architecture Google is implementing. The architecture itself is the major undertaking here.

Deployment of services will take place through a client-side gadget that communicates using a derivative of the existing OpenSocial API, coupled with server-side applications written in such common languages as Python and Java. So Google isn't re-inventing the wheel here either. But since Wave isn't really an app yet, and isn't a fully-fleshed out architecture yet, and doesn't have a complete platform yet, it may lack the impetus and momentum that .NET and Java have to enable good ideas to come to fruition. It does have the scale it needs, however, and that's the biggest ace in Google's hand right now.