On Fri, 9 Aug 2019 at 03:58, Lucas Pardue <lucaspardue.24.7@gmail.com> 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/
Received on Thursday, 8 August 2019 22:16:39 UTC