I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this.
Google is the least scary company in this regard. They're putting their extensions out into public hands instead of using an "embrace/extend" model. SPDY is open, soon to become an official web standard, and implemented by popular web server software and browsers (nginx, apache, firefox). The same is true of Chromium as well, the core of Chrome.
I'd go so far as to say that in these areas Google is serving as a model corporate citizen, and I wish others would imitate them.
SPDY was heavily used by Google back when it was basically "do what Google do", putting other browser developers under pressure to implement it somehow or be seen as slower. (There was nominally documentation of how it worked. It was wrong.)
Having open-source implementation do not mean you're not going to "embrass and extend". It's a common misconception.
If you're the only big player, that your stuff is open just means others can also implement your protocol. But since you're the only big player, they can't have their protocol.
So you can make your protocol work for you, do things that will bring you more money, and have it open-source, AND force it upon others.
Forking it doesn't mean shit if you're forced to use it to access _ANYTHING_ anyways.
Chrome isn't the only major web browser. Google doesn't have the power to unilaterally decide what all the other browsers will do. Nor does it look like they're trying to get that power; they give hundreds of millions of dollars to Mozilla, one of Chrome's major competitors, and the Mozilla people don't always go along with what Google wants.
>I'd go so far as to say that in these areas Google is serving as a model corporate citizen.
Well that is a curious way to look at it.
Instead of working with other companies to define a common standard they force it through attrition. That's the exact opposite of how this sort of thing should work.
And given Google's disgraceful behaviour in abusing the FRAND process they are hardly a model citizen by any measure.
Sorry, but standards aren't formed in committees, they are standardized there.
The right way to do this is: Put out your stuff, get others to implement it, everyone has experiences, get together and standardize based on those experiences.
This is why folks like IETF rely on "rough consensus and running code" when standardizing.
I always see this idea that companies should get together in a room and define protocols, and having seen standards orgs that do this, it scares the hell out of me.
Exactly, ask the ISO how well the standards specified by their OSI reference model [1] competed with TCP/IP et al. The only substantial remnant of the OSI network standardization process today is the generic concept of protocol layers.
Or see the HTML standardization process. Or a hundred other examples.
Standardization almost always follows implementation, not the other way around.
Okay, can you name some standards which were created by multiple companies working together? (I'm not talking about maintenance -- HTML was invented by Tim Berners-Lee, SGML came out of IBM, JavaScript was Netscape, etc.)
The Java Community Process back in the day was a good example of how lots of large companies working together could define a standard and yet still leave room for innovation.
H.264 and WiFi standards are recent examples of a lot of companies working together.
Yeah, but 90% of those standards were TERRIBLE. Like, GOD AWFUL. EJB? SOAP?
It's the hangover from those standards that leaves kids today thinking that Python or Ruby are simpler than Java.
Eventually the JCP turned into "take popular open source ideas like hibernate and spring, and bless them with a JCP number". Which worked a lot better, and each of those individual projects was usually launched by an individual or small group initially.
The language Java is simpler than the language Python or Ruby. Fewer keywords, those keywords do fewer things.
Ruby and Python seem simpler for most web work due to better frameworks and dynamic typing, which is less simple than static typing, but is easier to work with in most web situations.
I guess I'm drawing a distinction between 'simple' and 'convenient'. Monkey patching in Ruby is not simple, but can be convenient and make rails possible.
I'm undecided whether Python/Ruby or Java are simpler.
At least to me dynamic typing seems much simpler than static typing: from a very very pragmatic view that just means no compile-time checks (?), and I'm not that good with Ruby, but I'd consider Pythons type system much simpler than Javas (Python has none of: primitive types, null, arrays, interfaces, visibility (well, there is name mangling for __...), enums, final/abstract, the checked/unchecked mess (look up what the correct way to catch exactly: all checked exceptions is!), casting, generics and everything that comes with it: have a look at the index at the left side of http://docs.oracle.com/javase/tutorial/java/generics/index.h... -- but to be fair Pythons type system has a couple of nontrivial features (metaclasses, multiple inheritance, ...) too)
Python/Ruby have a lot of very useful language features which make the languages much less of a pain to use than Java (the language), but for any meaningful comparison of language complexity you'd surely also have to consider the intricacies of the underlying VMs. The Java VM is quite complex and also quite powerful. For simple programs that don't require high performance or efficient memory management or whatnot that might not matter much though.
[Now, after having written this, I don't think its possible that any of the three languages is strictly simpler than any of the other ones.]
BrainF##k has even fewer keywords than Java, that doesn't make it simple.
I understand your point. Ruby and Python both have dynamic behaviour which makes it difficult to predict ahead of time what will happen when a program is run. In practice, however, the full range of possibilities is never exercised. It's not enough to look only at the language specification when you make these generalizations.
EDIT: TL;DR, essentially what matters is not the complexity of the language, but the complexity of programs written in the language.
The standards weren't terrible it was the entire concepts themselves and reflective of that era of computing. Most people thought XML was the future of the world and component architectures would be how all business software would be written. Little did we know.
But I still use SOAP everyday with Java, .Net, iOS and JS clients. So the benefits of companies working on commons standards is still pretty clear.
It's not just XML. Why would you ever choose SOAP over a simple REST endpoint? If you use SOAP frequently, have you used jaxb or jaxrpc? Those things were awful.
The systemic problem, which isn't just hindsight, is that you had 6 corporate vendors, each with their own internal politics, in a room with cross-corporate politics, creating a standard. Of course it will be a bloated monstrosity. It's not just hindsight to say that, that arrangement could turn all kinds of great ideas into disasters.
>Why would you ever choose SOAP over a simple REST endpoint?
I thought the obvious answer was always tooling. Point Visual Studio at WSDL, and immediately get IntelliSense and go to town. Take your easy "object oriented" designs, and pop them on the web, with less of the trouble of DCOM or CORBA, and more security. But of course it only works if the tooling is in place, and there was probably only a couple of interoperable stacks.
But at least there was a real reason, and serious value for a lot of developers. To compare, JSON doesn't even have a standard date format defined.
SOAP/WSDL has IDE support and various tooling because it would be almost unusable without it.
Imagine doing SOAP entirely by hand, with a semi-complicated WSDL. It's a nightmare. Doing a RESTful service based on JSON data is not just not a nightmare, it's a breeze, with no need for any of the tooling you describe and with, in my opinion, absolutely no difference in API richness, interoperability, security, quality etc.
If they'd announced this before they had a working implementation then Microsoft would have either created their own competing standard or wanted changes that only benefit themselves and slowed down development.
AFTER EDIT:
Why the downvote?
Ok, maybe I shouldn't have singled out Microsoft, but I think their past behaviour explains a lot the way Google are behaving now. I'm thinking in particular of what happened with XForms and WebGL.
Seriously, why the downvotes? I don't think developing in secret is how things should be done (in a perfect world). I'm just theorising why Google might have chosen to work that way. Is this not a reasonable motive, or is there a better explanation for their behaviour?
They're still right, it is a security risk.
Now, it doesn't mean we shouldn't have it. But it is one. Heck, the well known chrome vulns of the past alone should show that.
Your kind of skepticism is ultimately one of the few things that holds corporations in check, so I am not discouraging you from persistently aiming it at Google, Facebook, et al.
But that being said, I was a full-time dev there for 5 years, and I can say with a (however misguided) degree of certainty: all of those projects have one goal in mind - to make the experience of using the web better. Whatever else is true about the dangers of monoculture, Google's intentions are benign.
I think it's entirely sensible to think about the influence that companies like Google are gaining.
Each individual component is a sensible step forwards, but there's no doubt that Google could choose to do some pretty anti-competitive things if they wanted, and in the future there will always be different, more short-term, management in charge
A big company will always have the potential to do harm. If it's not about what they're doing, but what they could do, then any company that has influence in a market needs to be taken down.
I'm not against companies having influence; the first thing I said was that I was all for innovation and what's the point of innovating if you won't be heard?
The point is that Google are in, not just a position of influence, but a position of control. Google don't need to seek the acceptance of the community at large for SPDY to be useful to them. This is a very different standpoint from, say, Mozilla.
arguably, google are well positioned to see where improvements to traffic protocols can be made due to both chrome's large market share and their massive traffic requirements for google search et al.
Later on if/when their protocols are finalised and released, I'm sure one standards body or another will work to integrate them.
SPDY, Dart and now this.