Alternative to Protocol Buffers.

[oob...@gmail.com]

Its good to see some real interest in alternatives to XML finally.
I've been working on a similar project to Protocol Buffers for years
now called Argot (www.einet.com.au). I'm just about to release a new
version with updates on documentation, etc. Maybe you google guys
should have a look. There's a few interesting concepts in Argot that
I don't think Protocol Buffers does. ie Handles dynamic type
agreement between client and server, self describing files, allows
multi-dimensional arrays, abstract types, extensions to data
definitions, and of course is binary and very fast.

At the moment it doesn't have the code generation that you do in
Protocol buffers, but that has been intentional at this stage.
Anyway, have a look, I'd be interested in what you think.

Regards,
David.

[Adewale Oshineye]

As long as we're suggesting alternatives I'd like to point out
XStream: http://xstream.codehaus.org/
I've used it in a number of projects over several years for everything
from config files for reporting systems to financial instruments in
investment banks. It's self-describing (because it's XML or JSON) and
incredibly simple to use. Most people never need to go beyond the 2
minute tutorial: http://xstream.codehaus.org/tutorial.html
Downside is that it's Java only.

2008/7/9 <oob...@gmail.com>:

[Yegor]

I have to agree with Adewale, having used XStream myself. The concept
is very similar to protobufs and it is very easy to use. The
difference is that XStream derives data structures from Java classes,
rather than a special language.

The problem, however, is that XStream is aimed at XML (clean and
optimized but XML) and it is being promoted as such by the developers,
although they do provide JSON drivers and I see no reason why they
couldn't implement a protobufs encoder or something similar. For a web-
scale distributed application, when we are talking about using a 20-
server farm vs 60-server farm, these things make a big difference.

Of course, the other problem is that as of now XStream will only work
in Java. Not in the sense that you cannot read XML generated by
XStream in other languages, but in the sense that you do not get
automatic bindings like you do in Java. protobufs will generate
bindings for multiple languages for you (potentially all major
languages). However, in defense of XStream, if you are using a
language which is not supported by protobufs it is easier to implement
an XML parser for XStream's XML than it is to implement a parser for
protobufs encoding.

Yegor