Re: If not JSON, what then ?

--------
In message <CABkgnnWqHTinXDNXxM7Lw9SBGCCPb-j6BgKF=wjWKXRUbfe1oQ@mail.gmail.com>, Martin Thomson writes:
>On 3 August 2016 at 19:45, Willy Tarreau <w@1wt.eu> wrote:

>> Such bytes are rare and will have a large huffman encoding in H2. Martin's
>> suggestion of '><' could be more efficient, though I haven't checked.
>
>I tend to think that we should not let hpack drive this.

Agreed to that, but if we can easily be huffman-friendly, we should.

>But we'd be defining a binary encoding.
>
>Binary avoids the nastiness with character encoding (just use UTF-8),
>makes numbers and dates much more numbery, and lets us tailor the
>other types to our needs.

What I'm trying to do here and now, is a data model and HTTP/1
serialization which by design overlaps as many existing headers
defined syntax as possible, to minimize the number of parsers
required now and in the future.

By leeching on existing H1 syntax we avoid the b64 hack and we don't
need to touch HPACK before this can go live.

For H3+'s HPACK-ism, we may decide to serialize these structured
headers as "native binary" rather than "text-compression", but until
we know more about H3, that is a premature decision.

The downside of this approach is that the RFC723x's "quoted string"
also carries "utf8-string" and "binary-blob" in this new syntax,
signposted by two new, backwards compatible escape sequences.

>I think that PHK is perfectly right in recognizing that we don't have
>complex needs.  I actually think that this is good.  Limitations are
>empowering.

Indeed.

>I said this privately to someone at the workshop, but my realization
>was that we currently have schema-aware parsing with extremely limited
>points of extension.  A revised system that supports that doesn't need
>to be very complex.  Even a single level map of string key to
>(optional) string value is more extensibility than we can sensibly
>defend.

As with HPACK/huffman, I don't see the need to heurstically restict
the data model, I would rather precisely restrict its use for
individual headers.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 3 August 2016 13:07:49 UTC