Re: #225: JFV Revisited

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

--------
In message <[e-mail]>, Mark Nottingham writes:

>There have been very few people who are excited about (A); rather, I 
>think people saw JSON as a (somewhat distasteful, but practical) means 
>to an end.  

Yes, that's my perception as well, but does that imply that any
alternative to JSON stands a chance at the end of the day ?

Some of us learned that lesson with HTTP2, where "all options were
open (as long as they are based on SPDY)".

If people think the "common structure" brain-storm I floated have
enough merit, I'll be happy to try to turn it into an I-D so we can
take it from there.

But I dont want to waste my time, if there is a "sub rosae" requirement
for the result to be JSON?

>You're the strongest proponent for (B); my perception (which I'm happy 
>to have corrected) is that most others are happy to wait for an 
>alternative encoding (e.g., in a future version of HTTP) to get the 
>efficiency gains.

Yes, I think it is important that we keep (B) firmly in view.

I fully agree that we will not reap any big gains until we do
HTTP[3-6] with that focus, so we should be careful already now, to
not make that future task any harder than it needs to be(come).

Moores Law ran out of steam a few years ago, but we still need to
handle higher and higher concentrations of traffic[1], so we can no
longer just lean back and expect Intel to solve our future performance
problems.

Poul-Henning

[1] Btw: Yes, Google *does* use load-balancers, and yes, those
people are very much of the same sentiment, even though they did
not participate in the workshop.

-- 
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.