Re: The HTTP vs SPDY debate

You're welcome to ask the browser implementors, but a new protocol
namespace is really a non-starter.  We can't kick protocol versioning out
to the users for sorting out.

>From a protocol specification perspective, SPDY does not mandate SSL.

>From a browser perspective, I don't think the browsers are going to be keen
on having multiple, experimental HTTP/2.0 or SPDY specs implemented
concurrently.  It's just a coding mess.

So we probably have to pick just one implementation per piece of software.
 As for what people implement, they should try the variants they think make
sense, and then come back to the group with information about what they
learned.

Mike


On Fri, Mar 30, 2012 at 9:07 AM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Mike,
>
> On Thu, Mar 29, 2012 at 03:26:44PM +0200, Mike Belshe wrote:
> > I thought the goal was to figure out HTTP/2.0; I hope that the goals of
> > SPDY are in-line with the goals of HTTP/2.0, and that ultimately SPDY
> just
> > goes away.
>
> Of course, but since there are obviously controversial points which some
> absolutely want and others really don't want, I think that having SPDY be
> the bleeding edge "next" HTTP version on which research is performed etc
> and having the "stable" HTTP version makes a lot of sense. After all,
> this is more or less what is happening today : you present some results
> with running code and deployments, you're still open to make some changes,
> and both you and Roberto also told me you have a fair number of exciting
> new features in mind for the future. So why not consider keeping HTTP and
> SPDY work side by side with HTTP getting backports from SPDY every few
> years ? Even if SPDY became HTTP2 tomorrow, at the end of the year you
> would not be satisfied because you'd have many new features that you would
> like to have again and you'd reopen the SPDY project !
>
> There will always be users and websites who like to live on the bleeding
> edge and running your latest spec because they benefit from it. Standards
> benefit from experimental results and must not frequently change. Having
> both live together would make each one benefit from the other. I think
> you will agree with me that in the future, changes to the standard will
> become more and more frequent in order to better address end users needs,
> and at the same time we need to maintain some stability for the server
> side, with a compatibility layer between the two. There's probably an
> emerging market for latest-spdy-to-stable-http gateways to allow people
> to live on the bleeding edge.
>
> Last point is that by making such a relation something publicly known,
> you can more easily make implementers aware of future requirements, and
> ask their vendors for compliance with the forthcoming new standard. It's
> just like in 1999 we had many vendors writing "Y2K compliant" on anything
> ranging from cars to spoons. But at least customers wanted to be sure.
>
> Really I think it makes sense to have stable and bleeding edge.
>
> We can discuss about this today if you like.
>
> Cheers,
> Willy
>
>