W3C home > Mailing lists > Public > www-tag@w3.org > December 2009

Re: EXI for HTTP? Re: Efficient XML Interchange (EXI) LC spec addresses ISSUE-30 (binaryXML-30)?

From: Robin Berjon <robin@berjon.com>
Date: Mon, 7 Dec 2009 13:06:38 +0100
Cc: Dan Connolly <connolly@w3.org>, www-tag@w3.org
Message-Id: <03126D3F-E4EB-4B76-BBA4-438999357504@berjon.com>
To: Tim Berners-Lee <timbl@w3.org>
Hi Tim,

On Dec 5, 2009, at 18:35 , Tim Berners-Lee wrote:
> By the way, has anyone looked at using EXI for HTTP and MIME?
> Toward solving the problems of always sending the same darn HTTP headers...
> One wouldn't normally suggest it but as Google seem to think spdy is better in binary, maybe a common interchange format would be a good idea....

Several years ago, and using something less efficient than EXI, but we found that gains were indeed good for some configurations. I'm afraid the exact details are lost, but from what I recall:

 - a pre-shared dictionary is where most of the gains come from.
 - User-Agent and Referer can be problematic, but Cookie can be a real killer  a way of storing session data more efficiently would help.
 - fine-tuning for dates and media types helps.

Either way, even though I don't recall sufficient details to make a solid claim as to whether it would be better than the SPDY approach I'm convinced there is reason to believe that the experiment is worth carrying out.

My understanding is that SPDY loads a pre-agreed (as per spec) dictionary into gzip, and then maintains that gzip stream open for all subsequent messages, which helps address the problem that gzip is bad on small messages. This puts the bar fairly high but I'd be surprised if EXI didn't do better (and certainly faster). Furthermore, requiring EXI at the HTTP layer means that it is de factor available for XML processing as well. In the same vein, I'm increasingly convinced that binary JSON would be a good idea.

Robin Berjon - http://berjon.com/
Received on Monday, 7 December 2009 12:07:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:31 UTC