Hacker News Reader

Comment by tentonova | Hacker News Reader

There are obviously much fast formats for that type of thing, but they have their own drawbacks which are significant. Protocol Buffers are crazy fast but aren't self describing or human readable.

Why does that matter? The fact that they aren't self-describing more or less requires that you use a published message definition, which solves one of the major problems of XML schemas -- nobody actually uses them, and many that do use them incorrectly.

XML is great for what it is, and it has its drawbacks, but as a universal transport it is pretty rad.

Having wasted far too much of my life on parsing XML documents, I simply can not agree.

XML as a universal transport just sucks compared to the modern alternatives.

View on HN

Are you pitting XML against Protocol Buffers? Because they are completely different things. Being self describing is a big deal.. it makes interchange far far easier and obvious. As does being human readable, debugging a web API in a browser or via curl is a serious plus.

Having just spent the past two days reverse engineering an API that used protocol buffers, I can tell you I would have much rather done it against XML. :)

As for parsing, I guess I don't get what the big deal is. I've long since given up on SAX parsers and occasionally use pull parsers, but for the majority of applications using a DOM parser gives you a very OO friendly approach to turning that XML into your objects, and it is dead simple. Sine the generated Protocol Buffer objects are immutable and can't be used as base classes, I suspect the amount of code to turn a 'message' to your domain objects and vice versa is very similar between protocol buffers and a DOM impl. At least it has been in my experience, neither is hard.

I've never seen value in self-describing or human readable messages. You need some kind of relatively unique identifier for the format of a given message and any optional payload, but beyond that, if a receiver doesn't have any code that knows what to do with a given message, what's the point of being able to deserialize it? And I think debugging an API without making tools is a waste of effort, for the same reason that you use curl rather than typing "POST..." into netcat.

Having just spent the past two days reverse engineering an API that used protocol buffers, I can tell you I would have much rather done it against XML.

Why didn't you have the descriptor files? Optimizing for ease of external reverse engineering seems rather counter to the authoring organization's actual goals.

If you want third parties to be able to interoperate, give them the descriptors you use.

As for parsing, I guess I don't get what the big deal is.

Writing lots of code to read and parse data types as text, especially when no schema is available, is time consuming.

Protobuf is necessarily validated. The input types are known-correct, conversion to the domain model is direct and straight-forward, and it's exceptionally easy to generate code or otherwise automatically deserialize to native representations.

I didn't have the descriptor files because it wasn't an officially supported API. And that happens, lots! Often times people aren't interested in nailing down their API enough to 'officially' publish an interface.. XML makes it easy for you to use it anyways.

Parsing XML doesn't include lots and lots of code, at least not for me. As I said, the amount of code to parse a Proto built class into my own datastructure is almost identical to me doing it from a DOM tree save for some type conversion.

The other plus is that proto buffers involve firing up those tools and incorporating them into your project. How often do you just want something really simple, say the current temp in a zip code? That's a few lines of code to pull out via XML, without the trouble of pulling down the proto buffer definition, building the classes for your language etc..

Reply on news.ycombinator.com