View Single Post
  #7 (permalink)  
Old 08-11-2008, 07:55 AM
kenetrix's Avatar
kenetrix kenetrix is offline
Member
 
Join Date: Aug 2008
Posts: 10
Default

Quote:
Originally Posted by Caro View Post
WOW Ken!!!

You know your stuff. And I would love to have that 'dumbed down' into simple language as to what it means.

I am gathering you are saying it will be a little quicker to get your search results?

In amongst that - are you also saying that it will enable us to access it for more searches without getting a slap on the wrist for doing too many?

I am impressed - very. Just not 100% clear.

Caro
Glad you found the post useful. I realize it is somewhat "techie", so let me try to "dumb it down" for you all.

Here's the scoop:

Before Protocol Buffers, XML was the primary method use to exchange data amongst servers, applications and systems.

The problem is that XML, being "text based", uses far too much space and bandwidth, and that problem only gets worse, the more extensively it is used.

This problem has always existed with XML, and it always will. XML is a great protocol to use for exchanging data, but it just doesn't scale all that well.

So, imagine an entity like Google. Everything they do, from search to the applications they have rolled out in recent years, totally relies on exchanging data from one entity to another, and that's on a MASSIVE scale, mind you.

So, in short, Google found itself running into the "brick wall", long before anyone else did, and decided that the text-based XML had to be replaced, and took matters into their own hands.

According to the Protocol Buffers documentation, it was initially developed in 2001 to address an index server request/response protocol that Google was having problems with.

Since then, it has become, symbolically, the "lingua franca" for data within Google.

It now has 48,162 message types defined in the Google code tree, across 12,183 .proto files.

That's great, because it shows it's already pretty robustly defined, and it's not just something that they came up with "on the fly" - it's a field-proven, widely used protocol that Google has been using "behind the scenes", in place of XML.

The time has come, however, for Protocol Buffers to expand to the next level, and replace XML within the "Google-sphere", which is what took place this weekend.

If you think about the effort involved in doing that roll-out correctly, it's a scary proposition.

Fortunately, Google has an enormous amount of brilliant software engineers, so they CAN do a roll-out like this successfully, like no one else can.

It is only because of the 30DC that the "public" (i.e. those of us in the 30DC) is even aware of "something going on", due to the tools employed (like Market Samurai, etc.), because we are more "sensitized" to it.

The great news, however, is that the Protocol Buffer roll-out is just about complete, and appears to be a total success.


Quote:
I am gathering you are saying it will be a little quicker to get your search results?
Well, yes ... but more than a "little quicker": Remember, Protocol Buffers cut transmission time to 1/20th to 1/100th of the time required by XML. So, I'd say it will be a much more than a "little quicker"!

Quote:
In amongst that - are you also saying that it will enable us to access it for more searches without getting a slap on the wrist for doing too many?
That's hard to say, honestly.

Technically, it has no direct correlation to the Protocol Buffers roll-out, and it's really more of a policy decision from Google's standpoint.

It is, however, perfectly feasible that the Protocol Buffer roll-out COULD have an appreciable influence on any Google relaxation of its policy regarding just what constitutes "too many searches", and thus "warrants a slap on the wrist".

Guess we'll have to just wait and see what the Big "G" decides in this regard.

I hope that made it a bit more understandable, at least as far as the importance of the Protocol Buffer roll-out goes, and its future impact on us all.

If you have any other questions on this, please feel free to ask away, and I'll answer them if I can.

-Ken
__________________
http://twitter.com/kenetrix
Reply With Quote