Re: Please admit defeat (was: Our Schedule)

-1


On Sun, May 25, 2014 at 11:34 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> In message <315A1736-1C33-403D-AC5F-6E488B880FAE@mnot.net>, Mark
> Nottingham wri
> tes:
>
> >The overwhelming preference expressed in the WG so far has been to work
> >to a tight schedule. HTTP/3 has already been discussed a bit, because we
> >acknowledge that we may not get everything right in HTTP/2, and there
> >are some things we haven't been able to do yet.
>
> This is probably the most damning thing in this entire fiasco:
>
> The Mythical Man-Month was published in 1975, and without even
> the slightest hint of room for exceptions, it told us to:
>
>         "Always throw the prototype away."
>
> The WG took the prototype SPDY was, before even completing its
> previous assignment, and wasted a lot of time and effort trying to
> goldplate over the warts and mistakes in it.
>
> And rather than "ohh, we get HTTP/2.0 almost for free", we found
> out that there are numerous hard problems that SPDY doesn't even
> get close to solving, and that we will need to make some simplifications
> in the evolved HTTP concept if we ever want to solve them.
>
> Now even the WG chair publically admits that the result is a qualified
> fiasco and that we will have to replace it with something better
> "sooner".
>
> So what exactly do we gain by continuing ?
>
> Wouldn't we get a better result from taking a much deeper look
> at the current cryptographic and privacy situation, rather than
> publish a protocol with a cryptographic band-aid which doesn't solve
> the problems and gets in the way in many applications ?
>
> Isn't publishing HTTP/2.0 as a "place-holder" is just a waste of
> everybodys time, and a needless code churn, leading to increased
> risk of security exposures and failure for no significant gains ?
>
> Wouldn't it be faster to go straight after the real goal, an
> protocol which CAN replace HTTP/1.1 in all scenarios and be
> an improvement in ALL scenarios ?
>
>
> Please admit defeat, and Do The Right Thing.
>
>
> I move that we:
>
>   * Credit SPDY as a very good and worthwhile prototype,
>
>   * Acknowlege that SPDY overwhelmingly showed that there are a lot
>     of room for improvement over HTTP/1.1,
>
>   * But cognizant of the problems we've run into, and in respect
>     for Fred Brooks sage advice we throw it out, now that we have
>     learned all that we can from it.
>
> and
>
>   * Immediately start the design a successor protocol to
>     HTTP/1.1, which through necessary simplifications of HTTP
>     semantics and based on what we learned from the SPDY prototype,
>     will become better than HTTP/1.1 for all uses and users.
>
>
> Poul-Henning
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>