[josteink]

SPDY is overrated and only has traction because Google decided to make it. So far the data shows that the severely limited gains it provides, it provides at the cost of significant complexity.

I sure as hell could appreciate a new HTTP-standard, which was brought to the field by having professionals (maybe even IETF!) work together and reason about things publically, not just have Google hijack the process, dump shit out, saying "that's what we have implemented. if you want to compete with us, you will have to take this package", and then after the fact release some docs and claim it's open.

You know. SPDY just smells bad wherever you look. I'd like for the new HTTP protocol to be something you can trust

[elktea]

> So far the data shows that the severely limited gains it provides, it provides at the cost of significant complexity.

Source?

[josteink]

HTTP: Stateless, simple, plain-text, open, extendable. One request, one resource. Etc.

SPDY: Not-stateless, not-plaintext, includes complecting factors like prioritization and multiplexing. I say that is several orders of magnitudes of increased complexity and uncertainty baked into a protocol.

Result: Much less than an order of magnitude in improved response-time.

I say SPDY comes at such a cost that it cannot be considered worth it. Especially when you consider it comes at the added cost of handing over control of one of internet's main protocol's to a single company to be developed behind closed doors, such as Google is already doing with SPDY.

I'm flabbegastered that people aren't reacting to this. Had Microsoft being doing anything like this, people would be calling their senators to start investigations. But with Google it is evidently all cool.

You'd think people would remember the cost of handing over the internet to one single company, when the results of last time we did that is still plaguing us today (IE).

As for source, this one should do: http://www.theverge.com/2012/5/3/2995881/google-spdy-speed-t...

[0xABADC0DA]

> I sure as hell could appreciate a new HTTP-standard, which was brought to the field by having professionals (maybe even IETF!) work together and reason about things publically

This is a good point, for instance the developers of Spdy don't actually compare it to HTTP pipelining. They don't measure the effect of 'head of line blocking', just assuming it is a major problem. They don't consider that the protocol performs worse than HTTP over satellite and similar links. Neither the design choices nor specific details have been vetted or backed up by real deliberations.

There are tons of ways a committee of experts could improve Spdy, but it looks like Google is just going to show up with their draft RFC and demand a rubber stamp.

But this is just typical Google. Even when they do work with committees they show up and for instance say 'add big integers to JavaScript or else' (the 'or else' being Dart).

[josteink]

Spdy is already being further developed behind closed door, like a closed standard, owned by Google.

This should really be enough of a reason not to trust them with the task of developing this protocol.

http://www.theverge.com/2012/5/3/2995881/google-spdy-speed-t...

[0xABADC0DA]

https://developers.google.com/speed/articles/spdy-for-mobile

- doesn't include DNS lookup times

- doesn't include packet loss

- doesn't compare to pipelining

First two mean the claimed speedup isn't measuring the whole real time. Third is just amazing... the stock Android browser even uses pipelining. Basically pipelining gives the same benefits as Spdy and they really, really don't want to admit this.

http://www.belshe.com/2012/03/29/comments-on-microsofts-spdy...

This is what I'm talking about... every one of Microsoft's changes he identifies as b-h is a positive change. That he can't see it I guess is a testament to being young and inexperienced.