#225: JFV Revisited

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

#225: JFV Revisited

Mark Nottingham-2
For those not following the issues list closely, Ilya is wondering whether browsers' implementation of ECMA-262 changes things for JFV:

  https://github.com/httpwg/http-extensions/issues/225

Thoughts (here or there)?

--
Mark Nottingham   https://www.mnot.net/


Reply | Threaded
Open this post in threaded view
|

Re: #225: JFV Revisited

Poul-Henning Kamp
--------
In message <[hidden email]>, Mark Nottingham writes:
>For those not following the issues list closely, Ilya is wondering =
>whether browsers' implementation of ECMA-262 changes things for JFV:
>
>  https://github.com/httpwg/http-extensions/issues/225
>
>Thoughts (here or there)?

<RANT>

  "it's not clear if and when such a format will come either…"

Please!

Can we stop the "WE NEED IT YESTERDAY!!" insanity and spend the
tiny amount of extra time it takes to not do half-assed jobs ?

At the workshop we heard a litany of "ohh..." regrets about H2, the
majority of which were raised before ratification, but steam-rolled
over because "we don't have time for that!"

There will not be any relevant or significant difference in how
long time it would take to get a header-JSON RFC out compared to
one based on my "common structure" brain-storming or for that matter
any third candidate starting from some other point:  The thing which
takes time is for people to pay attention and make up their mind,
not the actual writing and implementation work.

</RANT>

With that out of the way, I am still struggling to find out what
problem we are trying to solve here?

Is it:

A) Allow people to use (restricted) JSON in headers, because people
   want to use JSON in headers (and will do it anyway).

Or is it:

B) Try to make headers more compute-efficient in preparation for
   future 100+Gbit/s speeds.

Or is it both ?

If it is only A), then we just need to pick a restricted JSON syntax.

(Of course we all know that the restrictions will be ignored in
practice:  "If it looks like JSON and it parses like JSON..." so
it is not entirely obvious that the restrictions are really worth
much effort on our part.)

If A) is not a hard requirement, then we should ditch JSON,
which is a square peg for many of our round holes, and instead
do something along the lines of my "common structure" brain-storm,
where we generalizes existing syntax and thus simplify things,
instead of adding yet another parser with pre-known issues.

We can of course have both, but that means we have to think much
harder about where we allow JSON and be more restrictive about the
JSON subsetting than we would need to in the A-only case.

So it seems to me that the question we need to settle is:

  Is being (a subset of) JSON a hard requirement ?

I vote "No".

Show of hands please...

Poul-Henning

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

Reply | Threaded
Open this post in threaded view
|

Re: #225: JFV Revisited

Mark Nottingham-2

> On 11 Aug 2016, at 5:49 PM, Poul-Henning Kamp <[hidden email]> wrote:

> With that out of the way, I am still struggling to find out what
> problem we are trying to solve here?
>
> Is it:
>
> A) Allow people to use (restricted) JSON in headers, because people
>   want to use JSON in headers (and will do it anyway).
>
> Or is it:
>
> B) Try to make headers more compute-efficient in preparation for
>   future 100+Gbit/s speeds.
>
> Or is it both ?

I'ts neither. The only thing we have broad agreement to, AFAICT, is

C) Specify conventions for people to use when defining headers, to avoid the most common footguns involved in that process (as well as generation, parsing, etc.).

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.  

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.


> I vote "No".
>
> Show of hands please...

That's not how things work, you know...


--
Mark Nottingham   https://www.mnot.net/


Reply | Threaded
Open this post in threaded view
|

Re: #225: JFV Revisited

Poul-Henning Kamp
--------
In message <[hidden email]>, 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
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Reply | Threaded
Open this post in threaded view
|

Re: #225: JFV Revisited

Martin Thomson-3
In reply to this post by Mark Nottingham-2
On 11 August 2016 at 14:52, Mark Nottingham <[hidden email]> wrote:
> Thoughts (here or there)?

I thought that the direction of the discussion was promising.  A
bespoke format, though more work, is entirely justified in this case.
I anticipate a draft-kamp-http-??? document in our near future that
collects up the best of the progress thus far.

Reply | Threaded
Open this post in threaded view
|

Re: #225: JFV Revisited

Amos Jeffries-2
On 12/08/2016 6:42 p.m., Martin Thomson wrote:
> On 11 August 2016 at 14:52, Mark Nottingham <[hidden email]> wrote:
>> Thoughts (here or there)?
>
> I thought that the direction of the discussion was promising.  A
> bespoke format, though more work, is entirely justified in this case.

Ditto. I was okay with JSON only for the short period where the Draft
was speaking of it as the format for use in RFCs (as replacement for
ABNF) not on-wire format for delivery.

What will be will be, but I wont pretend to like it (JSON). Even YAML
would be better than JSON, but that would require use of obs-fold.

Amos


Reply | Threaded
Open this post in threaded view
|

Re: #225: JFV Revisited

Julian Reschke
On 2016-08-12 09:03, Amos Jeffries wrote:

> On 12/08/2016 6:42 p.m., Martin Thomson wrote:
>> On 11 August 2016 at 14:52, Mark Nottingham <[hidden email]> wrote:
>>> Thoughts (here or there)?
>>
>> I thought that the direction of the discussion was promising.  A
>> bespoke format, though more work, is entirely justified in this case.
>
> Ditto. I was okay with JSON only for the short period where the Draft
> was speaking of it as the format for use in RFCs (as replacement for
> ABNF) not on-wire format for delivery.

It never did that.

> ...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: #225: JFV Revisited

Amos Jeffries-2
On 13/08/2016 3:08 a.m., Julian Reschke wrote:

> On 2016-08-12 09:03, Amos Jeffries wrote:
>> On 12/08/2016 6:42 p.m., Martin Thomson wrote:
>>> On 11 August 2016 at 14:52, Mark Nottingham wrote:
>>>> Thoughts (here or there)?
>>>
>>> I thought that the direction of the discussion was promising.  A
>>> bespoke format, though more work, is entirely justified in this case.
>>
>> Ditto. I was okay with JSON only for the short period where the Draft
>> was speaking of it as the format for use in RFCs (as replacement for
>> ABNF) not on-wire format for delivery.
>
> It never did that.
>

Well the text in the pre- ietf'96 Draft certainly fooled me.

Amos


Reply | Threaded
Open this post in threaded view
|

Re: #225: JFV Revisited

Ilya Grigorik
On Thu, Aug 11, 2016 at 12:53 AM, Mark Nottingham <[hidden email]> wrote:
C) Specify conventions for people to use when defining headers, to avoid the most common footguns involved in that process (as well as generation, parsing, etc.).... I think people saw JSON as a (... snip ... practical) means to an end.

^ yes, that.

On Thu, Aug 11, 2016 at 1:21 AM, Poul-Henning Kamp <[hidden email]> wrote:
But I dont want to waste my time, if there is a "sub rosae" requirement
for the result to be JSON?

No, there isn't. But JSON, despite the downsides that have been brought up here, *is* very appealing on a practical level.

I'd be more than happy to see viable alternative proposals that address all of the above points.

On Fri, Aug 12, 2016 at 9:53 AM, Amos Jeffries <[hidden email]> wrote:
On 13/08/2016 3:08 a.m., Julian Reschke wrote:
> On 2016-08-12 09:03, Amos Jeffries wrote:
>> On 12/08/2016 6:42 p.m., Martin Thomson wrote:
>>> On 11 August 2016 at 14:52, Mark Nottingham wrote:
>>>> Thoughts (here or there)?
>>>
>>> I thought that the direction of the discussion was promising.  A
>>> bespoke format, though more work, is entirely justified in this case.
>>
>> Ditto. I was okay with JSON only for the short period where the Draft
>> was speaking of it as the format for use in RFCs (as replacement for
>> ABNF) not on-wire format for delivery.
>
> It never did that.
>

Well the text in the pre- ietf'96 Draft certainly fooled me.

Amos