Re: new type number versus repurpose of existing field | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities

[Matthew Kerwin <[e-mail]>]

On Fri, 9 Aug 2019 at 03:58, Lucas Pardue <[e-mail]>
wrote:

> Note that it is not my suggestion to do the experiment this way. However,
> one could theorise that the work required to support generating, sending,
> receiving and processing new non-core frame types is greater than
> implementing some conditional code inside the frame parser.
>

One could also theorise the opposite.  For example: if someone had thought
to construct their core H2 engine in such a way that it offloads extension
values to modular/pluggable handlers.

It doesn't make sense to override an auxiliary frame like that, especially
just to appease implementers -- it's not like PRIORITY is welded to the
heart of the machine, like HEADERS.

Yes frames are cheap, but they also offer an API surface that things get
> sticky to. For example, reporting and metrics based on frame type counts
> etc. That adds more overhead to an ad-hoc short-lived data-gathering
> experiment.
>

Good?  Resist the sticky interface.  (BTW, on metrics: how much easier is
it to report on "unknown frame type 0xD" as opposed to "frame that looks
like 0x2 but actually isn't because of the contents of some settings frames
sent elsewhere on this connection"?)

Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/