Just catching up on my reading for the last few weeks and I see that Google has open-sourced something called Protocol Buffers. A bit of a yawn really, but interesting from the perspective of adding a new animal into that endless zoo of rpc protocols. Actually, Protocol Buffers are not quite rpc, but actually very reminiscient of XDR which was invented about 12 years ago.
Mark Pilgrim gives a good overview and the comments are interesting to peruse.
Ted Neward writes a really nice discussion of Protocol Buffers (and binary representation in general) versus XML.
Meanwhile, Steve Vinoski begs Google to back off from the “gee we can do rpc with this…” perspective.
Ultimately I ask the question “why do you want yet another binary encoding format”? I think Ted Neward sums it up well:
In the end, if you want an endpoint that is loosely coupled and offers the maximum flexibility, stick with XML, either wrapped in a SOAP envelope or in a RESTful envelope as dictated by the underlying transport (which means HTTP, since REST over anything else has never really been defined clearly by the Restafarians). If you need a binary format, then Protocol Buffers are certainly one answer… but so is ICE, or even CORBA (though this is fast losing its appeal thanks to the slow decline of the players in this space). Don’t lose sight of the technical advantages or disadvantages of each of those solutions just because something has the Google name on it.
2 comments ↓
OK, I’ll bite. You ask “why do you want yet another binary encoding format?”
To a large extent this conversation spanning these blogs is related to enterprise systems, however, the requirement for communications is much wider than this. There’s a huge gap in the tools and technology to deal with the emerging smart devices. Look at the ZigBee technology stack, HomePlug, or other emerging transports. The need binary communication protocols and the best we’ve got is a handfull of ASN.1, XDR, etc.
Obviously if Google are developing this solution they’re not happy with all the current solutions out there now. All these so called experts have decided that what is available solves all the problems. They don’t. More research and experimentation is required. The best way to do this is release things like Protocol Buffers and let the world that see a need in these to innovate and improve on them.
And Yes, if you look at the link I posted, you’ll see that I’m another developer of alternative binary encoding formats. It does a job that Protocol Buffers, ASN.1,XDR, etc don’t do which is why I’m interested in researching it. The fact is that many of the concepts of loose coupling that is found in XML can be applied to binary using the right encoding formats. This is the area my format Argot is exploring.
We will need more encoding formats until we have a set that is as flexible and as well endorsed as TCP/IP is for transport. We are no-where near that point now. Yes, we don’t just need one more encoding formats, we need a whole lot more encoding formats. We need to let them breed and watch them evolve into the fittest for the job. Right now, all I see if everyone try and shoot anything new that appears saying that its a “not invented here” syndrome or other such. The fact is, there’s so few solutions in this space that business need to develop these new protocols to fill the huge gaps that exist.
Rant over.
Great comments David and point taken with the embedded systems requirements.
I guess the question is whether Google are aiming at embedded systems or enterprise systems. My point is that the enterprise systems space is already crowded with protocols to the point of confusion.
Embedded systems and ubiquitous computing is a whole ‘nother area.
Leave a Comment