Google hates XML
by Ric Johnson
It is great that Google is contributing to the community and is showing the world how their system works, but I wonder if the inmates have taken over the asylum. I am a software engineer, so I enjoy the technical information, but I also ran my own company, and evolved to view problems from the business end. If you let the 'engineers run the show', then you get a very narrow viewpoint.
I think we have a severe ‘Not invented here’ syndrome inside Google.
24 Comments
DeWitt Clinton 2008-07-11 11:22:52 |
Hi Ric,
|
Eric Jain 2008-07-11 11:24:31 |
Well there is no X on Google, or is there? :-)
|
James Bennett 2008-07-11 11:27:30 |
See, me, I look at the guys who do a better job working with markup than anyone else on the planet, and hear them say "XML didn't suit what we needed", and think "wow, they probably know their own needs and the limitations of available tools better than I do".
|
Ric 2008-07-11 11:48:08 |
@Dewitt: I know Google does not really hate XML, but sometimes it seems like it! I use a lot of your protocols, but mostly in JSON. I am SURE 'Protocol Buffers' are kewl, but my point is that you guys could get XML to work. I am willing to bet someone will make something similar in less than a year that uses more structured markup. You game? By the way - the website you linked to seems to be down. @Eric: The whole point of my post is that Google created a whole NEW markup instead of improving XML libraries. Then the 200 times speed would go down to 100, then 50, then .... @James: I agree XML is not the best tool for EVERYTHING, but it seems they invented a new markup that depends more on context, which limits the reuse-ability. |
dbt 2008-07-11 12:00:47 |
Excuse me, have you ever dealt with systems that have to transmit hundreds of thousands of messages per second?
|
Andrew 2008-07-12 00:23:53 |
I think your misunderstanding the use of this technology. Its there for low latency message passing and isn't really designed for much else. The google engineers don't hate XML, its just that for the number of transactions that they are talking about, XML is just too bulky. Yes you can compress the XML, but once again it increases the latency.It doesn't replace xml, and you don't get the flexibility, validation etc.. that you get with XML. For _this_ usecase, those don't apply. What they want is small, fast markup that is quickly parsable. They don't need to be able to query it, display it in different ways etc..
|
John 2008-07-12 04:22:48 |
Sorry, but this was just the most stupid blog post I've read in a while. This post feels like it is written by a 14 year old who is pissed that somebody doesn't like xml. Well I'd say there are reasons not to like it but as DeWitt pointed out, Google is far away from hating xml.
|
Henning 2008-07-12 07:24:10 |
Ric, It seems to me that the opinion you expressed in your post is rather misguided or from a narrow point of view. Xml is great for many things and I use it on a daily basis for my work and could not imagine solving certain problems without it. However, the statement that Kenton Varda makes in the announcement of open sourcing Google’s Protocol Buffers makes perfect sense when considering the environment that they are working in. I work for a company that makes applications that processes large amounts of data (hundreds of millions of records per hour) and while we use xml to communicate on the front end and to configure our applications, early tests showed that it is impractical and much too expensive to do so in our backend systems. For certain things it simply adds an extra layer of processing that is not necessary and only costs you cycles. Even if you can “make xml run in circles” and parsing it only takes a fraction of a second longer than reading a binary format, multiply that fraction times a few hundred million (records) or in the case of Google probably billions and you end up with a huge chunk of time (on the order of hours or even days, depending on your data). It always depends! Cheers, Hans |
Christophe 2008-07-12 19:00:23 |
The shortest possible Protocol Buffers message, encoding a single digit number, is three bytes.
|
orlando_ombzzz 2008-07-12 21:16:11 |
XML was not designed for efficient data interchange between applications or processes.
|
Lopsterrrr 2008-07-13 09:22:50 |
Steinberg Cubase SX 2.2.0.33 software |
charles 2008-07-13 10:02:25 |
Now I understand! You are a genius! If you decide to actually do something, Google will weep and cry... |
Dan McCreary 2008-07-13 11:05:32 |
It seems like Protocol Buffers is just XML using attributes instead of elements.
|
Dan McCreary 2008-07-13 11:14:09 |
Here it is with the escape characters:
|
Anonymous Coward 2008-07-13 16:28:39 |
If you want a challenge, I suggest you write an internet scale XMPP implementation using run-of-the-mill XML parsers as your only parsing tool. No cheating; no writing your own shallow parser to tokenize stanzas at the border.
|
Requiem 2008-07-13 16:58:32 |
Protobuffers and XML address different problems.
|
Christophe 2008-07-13 19:34:48 |
@Dan McCreary:
|
Andre 2008-07-14 07:48:38 |
Ric: As many before me have pointed out, Protocol Buffers are more a marshalling solution (like ASN.1) than a document language (like JSON or XML). Different problems, different solutions. By the way, your NIH-argument would probably make more sense when comparing Protocol Buffers to other marshalling solutions.
|
PsydayKes 2008-07-14 21:50:56 |
Please visit my new blog http://botlog.ru/ Let's talk about it |
Afrodit@ 2008-07-16 21:03:11 |
Hello I want to learn, whether colour of the car influences insurance payment I thank While |
Gregory Pierce 2008-07-18 04:07:21 |
Ric, I'm afraid that your blog post is somewhat misguided. While Google did create new markup for this, they really did it in the same vein as JSON. In fact I'm sure the authors were heavily influenced by it. As stated before XML is not the best way to do things all the time. It may be the cleanest way, it may even be the most standard way, but rarely is it the most efficient way. XML tends to be fat, even when you need to deal with optimized forms of it. Some of the methods you describe XML/zip would require extra time to take it from the 'zipped' form to its uncompressed for so that you can then parse it - either that or have more complex code to parse it.
|
jimmy Zhang 2008-07-23 23:33:22 |
XML doesn't have a performance issue.. XML parsers have performance issues new parsers such as vtd-xml are dramatically better
|
M. 2008-07-25 13:00:10 |
I'd point the author of the article to: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
|
vijayanarasimha 2008-07-31 03:06:16 |
xml |