Re: The use of binary data in any part of HTTP 2.0 is not good

[Roberto Peon <[e-mail]>]

Text formats are, surprisingly, not easier to debug in my experience.

Admittedly, they only require a text editor to examine, but, for a binary
protocol, that is easy to remedy with a short utility. The ambiguity of how
to parse that text format, however makes this examination more time
consuming and error prone.

In terms of total complexity, binary framed protocols are often far
simpler, and thus more robust. In terms of total lines of code, a binary
framer plus utility to present the data in human readable format is still
less complex and smaller than most text framed protocols. In terms of CPU
consumption, binary framed protocols are often faster.

If you'd like to make a fast http parser, I'm happy to give you a binary
framed version which will be significantly faster, smaller in lines of
code, and more memory efficient.

-=R
On Jan 20, 2013 3:26 PM, "Tim Bray" <[e-mail]> wrote:

> Would it be possible to be data-driven?  Textual formats are
> well-known to be easier to debug; but clearly, if there’s a
> substantial performance benefit to going all-binary, so be it. So what
> is the advantage, quantitatively? -T
>
> On Sun, Jan 20, 2013 at 3:04 PM, Mark Nottingham <[e-mail]> wrote:
> > In one of our recent meetings, one of the grey-bearded IETF old-timers
> (I forget which, sorry) said that a textual-protocol was a nice-to-have,
> but that it shouldn't be a determining factor in design.
> >
> > I.e., if you can get everything you need out of a protocol, *and* make
> it textual, do so, but if it detracts from the value you get from it, don't
> let that constrain you.
> >
> > FWIW, I think that's a good rule of thumb. However, this means that the
> community is going to need *excellent* tooling for analysing, debugging,
> etc. HTTP traffic; and I don't just mean a Wireshark plugin!
> >
> > Cheers,
> >
> >
> > On 21/01/2013, at 9:36 AM, William Chan (陈智昌) <[e-mail]>
> wrote:
> >
> >> There are many advantages to using binary data. If you would like a
> >> textual representation of a protocol, I advise using a utility to
> >> generate one for you.
> >>
> >> On Sun, Jan 20, 2013 at 2:20 PM, Pablo <[e-mail]> wrote:
> >>> Hello,
> >>>
> >>>   I have readed this document
> >>> http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1 today
> [1].
> >>>
> >>> I just wanted to say that I think that the use of any binary data
> (framing,
> >>> header compression, etc.) in any place of the "header" part of HTTP
> protocol
> >>> is not good; so, please only use plaintext for HTTP 2.0 because,
> otherwise,
> >>> that will make very difficult to "see" the headers's protocol :)
> >>>
> >>> Thats all,
> >>> Thanks for reading this few lines, sorry for my basic English, and I
> hope
> >>> that you can re-think all this of using binary data in any part of
> HTTP X.X
> >>> (ej: session layer).
> >>>
> >>>
> >>> [1] I started knowing about HTTP 2.0 here:
> >>> http://webscannotes.com/2012/10/09/http-2-0-officially-in-the-works/
> >>>
> >>
> >
> > --
> > Mark Nottingham   http://www.mnot.net/
> >
> >
> >
> >
>
>