Re: If not JSON, what then ?

["Poul-Henning Kamp" <[e-mail]>]

--------
In message <[e-mail]>, Martin Thomson writes:
>On 3 August 2016 at 15:07, Poul-Henning Kamp <[e-mail]> wrote:
>>
>> 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.
>
>I'm skeptical that you will be able to do that without sacrificing
>something.

There are always tradeoffs.

For instance the HTTP/1 serialization should not be a security risk
if it pops up in a traditional application which does naïve
stringprocessing on HTTP headers.

It would also be nice if HTTP/1 can still be debugged by eye, without
needing b64 decoding, but that is much less important than not
blowing up all PHP or JS programs.

>And if the point of the exercise is to define the one true
>format (or three or some small number) that is used hereafter,

It doesn't have to be perfect, I'll be happy if we can come up with
a common structure which is so usable, that the exceptions become
rare and well considered.

>I don't see much inherent value in minimizing the distance between the
>old thing and the new thing.

Like the HPACK/huffman thing:  I fully agree.  But if the minimal
distance does not hurt us going forward, we would be silly to
increase it needlessly.

And please remember:  I deliberately approached this from the far
opposite side relative to adopting JSON, in order to another data
point on the size of the solution space.

I liked the outcome, it was surprisingly much better than I had
expected, but I would be very surprised if there isn't a better
solution once we ponder it more.

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