RE: Would a header/schema compiler help?

I also have trouble with the use of compression over the headers for two reasons:

1) While we know that compression can work wonders on entity bodies, it obscures the headers which are critical for inspection and manipulation by everybody down the message path.

2) Further, it is unclear whether there is any noticeable performance gain from doing so. The only headers that today are open-ended are really User-Agent and Set-Cookie/Cookie pairs. In all our data where we don't include these headers we see no gain from using header compression whatsoever as long as you are conservative in how many headers you choose to include.

In other words, based on the data we have, focusing on optimizing UA and cookie headers may offer tangible performance gains.

Unless we can find convincing data I would argue that we should start the header discussion by focusing on the headers that we know have problems and then go from there.

Henrik

-----Original Message-----
From: Phillip Hallam-Baker [mailto:hallam@gmail.com] 
Sent: Tuesday, July 17, 2012 07:10
To: ietf-http-wg@w3.org Group
Subject: Would a header/schema compiler help?

One of the design choices I find a little troubling in SPDY is the use of header compression over a compact representation.

Compression algorithms worry me because the only way I can implement them is to call someone's library. I can write my own code to implement RFC822 header parsing. In fact I have done so a dozen times at least.

ASN.1 and XML schemas are undoubtedly how to do a protocol 'right' in the academic sense of get some good abstractions in there. But they both come with hideous baggage. ASN.1 started too large and has been tweaked endlessly until it became nonsense. XML encoding is bloated and XML Schema drags in the whole SGML legacy that the WG was meant to chuck in the dustbin. I dare you to use a model group in your next XML spec.


But JSON proves that it does not have to be that way. Over the past couple of months I have put together what amounts to a schema compiler for JSON. I am currently working on putting the compiler and the tools used to build it out on Github under an open source license.

Unlike your regular schema compiler, this one makes it easy to retarget the code generation at a different language. Writing a JSON back end for C# took me about a week (and I was developing the tool at the same time). I could modify that code to generate C in a day. Want python, perl, Java, no problem.

The JSON protocol synthesizer is built using the Goedel meta-synthesizer (which is of course written in itself). Comodo owns the protocol synth, I own the meta-synth. They should both be up on github under an MIT license in a few weeks.


It seems to me that it would be useful to have a compiler for RFC822 style headers. The basic strategy being similar to a 'jack up' house renovation. First we jack up the level of abstraction in the HTTP spec by defining the headers in terms of a schema that is designed for that specific purpose. Then we build in the new ground floor (aka encoding) underneath it.


--
Website: http://hallambaker.com/

Received on Thursday, 2 August 2012 20:55:27 UTC