4 ms·

I don't understand this negativity towards QUIC/Dart/NaCL/Pepper etc. which are exemplary open-source efforts. By your definition Mozilla's (your employer's) a

by kjksf 12y ago

I don't understand this negativity towards QUIC/Dart/NaCL/Pepper etc. which are exemplary open-source efforts. By your definition Mozilla's (your employer's) asm.js and Rust are also proprietary. Somehow I doubt that you jump on every thread about asm.js or Rust to point out how proprietary they are or how they are implemented as a giant pile of C++. Double standards. There have been plenty of research and work even in standard bodies like IETF that try to implement a better tcp/ip-like protocol. They all went nowhere because at this point in time, you can't just have some guys in a room to design a new transmission protocol and have it taken seriously by anyone that matters (Google/Apple/Microsoft/Mozilla). Google is following the only realistic route: implement something, test it in a scale large enough to conclusively show an improvement and then standardize it. This is exactly how HTTP/2 happened. We should be cheering them on instead of spreading FUD because it doesn't live up to your impossible standard of non-proprieterness.

magicalist 12y ago
I'm not entirely sure it's helpful to lump all of those together; there is at least some difference in kind. I think dragonwriter's sibling comment to yours is pretty apt here. It's hard to tell the difference between something that will be submitted to standards bodies any day now and something that really will be submitted to standards bodies any day now. At a certain point (with e.g. Pepper) the statute of limitations runs out and you have to assume it's just going to be an open-source but proprietary API. Of course, whether or not overloading "proprietary" is useful is a different discussion. Mostly it seems these conversations eventually just devolve into arguments over definitions of the word for no real insight.
pcwalton 12y ago
> Somehow I doubt that you jump on every thread about asm.js or Rust to point out how proprietary they are or how they are implemented as a giant pile of C++. Double standards. asm.js isn't a new protocol, and so isn't proprietary according to that definition. It's a subset of JavaScript (to be specific, ES6, including such extensions such as Math.imul). You can implement asm.js by simply implementing the open, multi-vendor ES6 standard. In fact, that's exactly what some projects, like JavaScriptCore, are doing. Rust isn't relevant, as it's not intended to be added to the Web. Adding <script type="text/rust"> to the browser would be a terrible idea for numerous reasons. Nobody has proposed it.
- rakoo 12y ago
  > Rust isn't relevant, as it's not intended to be added to the Web "Proprietary" as used here isn't limited to the Web.
  - pcwalton 12y ago
    Point taken, and you're right that in a certain sense Rust is proprietary, with all of the very real downsides that that entails (for example, the risk of tight coupling of programs to rustc, as hard as we try to prevent it). But I still think it's a fairly irrelevant thing to bring up, because Rust isn't targeting a large, open, multi-vendor ecosystem (as I specified in my original post). If Rust catches on, no other vendor is going to be forced to implement anything; nobody outside the current Rust community is even asking for a seat at the design table. The only real downstream dependency that the success of Rust might impact is LLVM, and we actually have maintained a pretty good relationship with the LLVM community from the start.
- tptacek 12y ago
  Plenty of IETF standardization efforts can be described as "a subset of Javascript" or even just "a bunch of Javascript APIs". WebCrypto, for instance, fits that bill. What makes QUIC so different from WebCrypto?
  - pcwalton 12y ago
    QUIC and Web Crypto are both things that need to be standardized, so I don't know what the implication is or how to respond to that statement. I do think there is a big difference between "a subset of JavaScript" and "a bunch of JavaScript APIs" from a standardization point of view. All engines have been implementing special optimizations for JavaScript subsets ever since the JS performance wars started. Nobody thinks we need to standardize polymorphic inline caches, for example, even though the set of JS code that is PIC-friendly is different from the set of JS code that is heavily polymorphic (and this distinction would be easy to describe formally if anyone cared to). asm.js is just an optimization writ large: the reason why it's not a protocol is that any conforming JavaScript implementation is also an asm.js implementation. I think people are reading a lot more into my posts than was intended. I'm not calling out QUIC specifically, since I'm not involved with the details of its standardization anyway. The point is simply that open source doesn't automatically mean non-proprietary.

by kjksf 12y ago

magicalist 12y ago

I'm not entirely sure it's helpful to lump all of those together; there is at least some difference in kind. I think dragonwriter's sibling comment to yours is pretty apt here. It's hard to tell the difference between something that will be submitted to standards bodies any day now and something that really will be submitted to standards bodies any day now. At a certain point (with e.g. Pepper) the statute of limitations runs out and you have to assume it's just going to be an open-source but proprietary API. Of course, whether or not overloading "proprietary" is useful is a different discussion. Mostly it seems these conversations eventually just devolve into arguments over definitions of the word for no real insight.

pcwalton 12y ago

> Somehow I doubt that you jump on every thread about asm.js or Rust to point out how proprietary they are or how they are implemented as a giant pile of C++. Double standards. asm.js isn't a new protocol, and so isn't proprietary according to that definition. It's a subset of JavaScript (to be specific, ES6, including such extensions such as Math.imul). You can implement asm.js by simply implementing the open, multi-vendor ES6 standard. In fact, that's exactly what some projects, like JavaScriptCore, are doing. Rust isn't relevant, as it's not intended to be added to the Web. Adding <script type="text/rust"> to the browser would be a terrible idea for numerous reasons. Nobody has proposed it.

rakoo 12y ago
> Rust isn't relevant, as it's not intended to be added to the Web "Proprietary" as used here isn't limited to the Web.
- pcwalton 12y ago
  Point taken, and you're right that in a certain sense Rust is proprietary, with all of the very real downsides that that entails (for example, the risk of tight coupling of programs to rustc, as hard as we try to prevent it). But I still think it's a fairly irrelevant thing to bring up, because Rust isn't targeting a large, open, multi-vendor ecosystem (as I specified in my original post). If Rust catches on, no other vendor is going to be forced to implement anything; nobody outside the current Rust community is even asking for a seat at the design table. The only real downstream dependency that the success of Rust might impact is LLVM, and we actually have maintained a pretty good relationship with the LLVM community from the start.
tptacek 12y ago
Plenty of IETF standardization efforts can be described as "a subset of Javascript" or even just "a bunch of Javascript APIs". WebCrypto, for instance, fits that bill. What makes QUIC so different from WebCrypto?
- pcwalton 12y ago
  QUIC and Web Crypto are both things that need to be standardized, so I don't know what the implication is or how to respond to that statement. I do think there is a big difference between "a subset of JavaScript" and "a bunch of JavaScript APIs" from a standardization point of view. All engines have been implementing special optimizations for JavaScript subsets ever since the JS performance wars started. Nobody thinks we need to standardize polymorphic inline caches, for example, even though the set of JS code that is PIC-friendly is different from the set of JS code that is heavily polymorphic (and this distinction would be easy to describe formally if anyone cared to). asm.js is just an optimization writ large: the reason why it's not a protocol is that any conforming JavaScript implementation is also an asm.js implementation. I think people are reading a lot more into my posts than was intended. I'm not calling out QUIC specifically, since I'm not involved with the details of its standardization anyway. The point is simply that open source doesn't automatically mean non-proprietary.