- From: Adrian Cole <adrian.f.cole@gmail.com>
- Date: Fri, 27 Jun 2014 11:22:34 -0600
- To: David Krauss <potswa@gmail.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>
Conflating implementation with being in favor of continuations is probably not accurate. Implementing isn't a vote for the idea, more just being compliant. In okhttp we had to implement continuations in order to be spec compliant. We deferred writing continuations until we got a bug report as the user overflowed 16k. Latest codebase is on -13 and supports continuation. In any codebase, I would love an opportunity to rip out complicated code for something simpler. I personally would love to rip out code I wrote in favor of jumbo frames. I loved ripping out code to support -13. Love isn't a requirement though, so if folks believe that continuation is a compromise worth continuing, I'm not going to make my own protocol :) -A On Fri, Jun 27, 2014 at 4:01 AM, David Krauss <potswa@gmail.com> wrote: > > On 2014–06–27, at 3:21 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > >> I would like to propose that CONTINUATION be removed to an extension >> as well then. >> >> Several people here have already said that they are not going to >> implement CONTINUATION and there is presently no way to negotiate >> if CONTINUATION will be available or not end-to-end. > > Perhaps I missed something, but who is implementing CONTINUATION? I only recall hearing from folks who were not. Are the results from interoperability testing public knowledge? It might be a good idea to give credit to those who’ve demonstrated good support. > > To my architecture, multiple frame blocks look a lot like jumbo frames. It could go either way. But implementing both is definitely the worst case, and the more popular alternative is going to happen at least first, if not ever. > >
Received on Friday, 27 June 2014 17:23:01 UTC