4 ms·

I can't tell if this is an alternative to something like QtWebKit. There doesn't seem to be any emphases on native code integration.

leoc 16y ago
> There doesn't seem to be any emphases on native code integration. Mozilla's actively opposed to any form of JS/native code integration, undoubtedly because that would dilute the effective proprietary control over the Web platform that it shares with a small group of fellow browser vendors. (And maybe because it would wound the personal vanity of its senior developers.) It's already briefing friendly journalists against Google NaCl http://www.theregister.co.uk/2010/06/25/mozilla_on_jaegermonkey_javascript_engine_extension/ http://www.theregister.co.uk/2010/06/25/mozilla_on_jaegermon... http://www.theregister.co.uk/2011/02/18/google_releases_first_native_client_sdk/ http://www.theregister.co.uk/2011/02/18/google_releases_firs... , using comically disingenuous arguments: oh, it's just too bad that NaCl hasn't been blessed by the web standards process that we ourselves control! Opera is behaving similarly: http://www.theregister.co.uk/2010/10/01/opera_on_google_native_client/ http://www.theregister.co.uk/2010/10/01/opera_on_google_nati... . Of course, it's another thing to extend this attitude to the desktop, where developers have plenty of alternatives to drinking the JS kool-aid. But presumably Mozilla is hoping that the accelerated-Javascript/"contemporary HTML" juggernaut will be powerful enough to sweep a good number of desktop developers along anyhow. Next Big Language and all that, after all.
- quanticle 16y ago
  How is Mozilla's control over the W3C HTML standards process proprietary in any way? Mozilla is only one of a number of vendors on the W3C, and is certainly not the most powerful of those vendors.
  - leoc 16y ago
    I didn't suggest that Mozilla has sole control over the HTML (etc.) standards. It's one of the five browser vendors who collectively have de facto control over the Web platform, and it's one of the four non-MS browser vendors who collectively have de facto control over "open Web standards". Thus, for instance, the reason that Google Native Client is not set fair to become an "open Web standard" is because three of the four non-MS vendors oppose it for reasons of self-interest. Similarly, it's going to have trouble getting real-world adoption because MS opposes it too, for basically the same reasons. You'll note how the desires or interests of other actors, like the non-browser-vendor W3C members or Web users and developers at large, play no role in the calculation.
    - tiles 16y ago
      > The reason that Google Native Client is not set fair to become an "open Web standard" is because three of the four non-MS vendors oppose it for reasons of self-interest. As a user, I don't want to see NaCl's compile-once-per-each-architecture model become part of the web. It's true browsers oppose it out of self interest, but NaCl has its own problems that haven't been solved. PNaCl is a good start and much more in the vein of an open web that isn't tied to a particular platform. And whatever benefits an Open Web, Mozilla will inevitably support, as it sustains their business model. NaCl doesn't do anything for browser makers, but it also doesn't help me as a user.
      - leoc 16y ago
        So what remaining problems with NaCl's compile-once-per-each-architecture model do you believe can't be solved by the combination of multi-architecture compilers (llvm, gcc ...) on the developer/server end and PNaCl on the client? Obviously the implementation is incomplete and immature, but Mozilla and Opera aren't even pretending that their opposition to NaCl is based on the immaturity of the implementation. > And whatever benefits an Open Web, Mozilla will inevitably support, as it sustains their business model. Mozilla inevitably supports and benefits from an Open Web only to the extent that you accept Mozilla's rather Newspeak definition of the Open Web as "a Web whose client API and runtime is under the shared control of a small group of browser vendors". If you have a less Orwellian kind of openness in mind, then it's clearly not true: Mozilla benefits from its shared control over the Web platform in largely the same way that MS benefits from its control over the Windows platform, and just like MS it has a strong self-interest in not seeing its platform "commoditised". As if that weren't perfectly clear already, then Chromeless underlines it. I assume you accept that Mozilla has a self-interest in seeing Chromeless succeed? The reason that Chromeless has a chance of hitting the big-time on the desktop is almost solely because Javascript and friends are popular on the Web client, and the ultimate reason for that is because JS and friends are bolted in and difficult to avoid on the web client.
        bzbarsky 16y ago
        Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked. It's not as arhictecture-dependent as assembly but the last time I looked you couldn't generate the same LLVM on x86 and x86-64, say. Has that changed? It looks like PNaCl aims to "solve" this problem by using 32-bit-targeted LLVM... including 32-bit pointer alignment. It's not immediately obvious how portable this would be to some hardware, and more importantly I'm not aware of any plans to support anything other than x86 and ARM initially (well, and x86-64 using its ability to run 32-bit code as far as I can tell). Am I just missing something on this front? If I'm not missing anything, then this project's main impact if it caught on would be to restrict the set of hardware on which you can access web content, which is NOT a good thing.
lloydhilaiel 16y ago
one way you can do native code integration with chromeless is using JSCtypes: https://wiki.mozilla.org/JSctypes https://wiki.mozilla.org/JSctypes I hacked up a trivial proof of concept on this branch: https://github.com/mozilla/chromeless/tree/jsctypes_play https://github.com/mozilla/chromeless/tree/jsctypes_play
- parbo 16y ago
  Does JSCtypes allow for js functions to be used as C callbacks, like Python's ctypes does?

leoc 16y ago

> There doesn't seem to be any emphases on native code integration. Mozilla's actively opposed to any form of JS/native code integration, undoubtedly because that would dilute the effective proprietary control over the Web platform that it shares with a small group of fellow browser vendors. (And maybe because it would wound the personal vanity of its senior developers.) It's already briefing friendly journalists against Google NaCl http://www.theregister.co.uk/2010/06/25/mozilla_on_jaegermonkey_javascript_engine_extension/ http://www.theregister.co.uk/2010/06/25/mozilla_on_jaegermon... http://www.theregister.co.uk/2011/02/18/google_releases_first_native_client_sdk/ http://www.theregister.co.uk/2011/02/18/google_releases_firs... , using comically disingenuous arguments: oh, it's just too bad that NaCl hasn't been blessed by the web standards process that we ourselves control! Opera is behaving similarly: http://www.theregister.co.uk/2010/10/01/opera_on_google_native_client/ http://www.theregister.co.uk/2010/10/01/opera_on_google_nati... . Of course, it's another thing to extend this attitude to the desktop, where developers have plenty of alternatives to drinking the JS kool-aid. But presumably Mozilla is hoping that the accelerated-Javascript/"contemporary HTML" juggernaut will be powerful enough to sweep a good number of desktop developers along anyhow. Next Big Language and all that, after all.

quanticle 16y ago
How is Mozilla's control over the W3C HTML standards process proprietary in any way? Mozilla is only one of a number of vendors on the W3C, and is certainly not the most powerful of those vendors.
- leoc 16y ago
  I didn't suggest that Mozilla has sole control over the HTML (etc.) standards. It's one of the five browser vendors who collectively have de facto control over the Web platform, and it's one of the four non-MS browser vendors who collectively have de facto control over "open Web standards". Thus, for instance, the reason that Google Native Client is not set fair to become an "open Web standard" is because three of the four non-MS vendors oppose it for reasons of self-interest. Similarly, it's going to have trouble getting real-world adoption because MS opposes it too, for basically the same reasons. You'll note how the desires or interests of other actors, like the non-browser-vendor W3C members or Web users and developers at large, play no role in the calculation.
  - tiles 16y ago
    > The reason that Google Native Client is not set fair to become an "open Web standard" is because three of the four non-MS vendors oppose it for reasons of self-interest. As a user, I don't want to see NaCl's compile-once-per-each-architecture model become part of the web. It's true browsers oppose it out of self interest, but NaCl has its own problems that haven't been solved. PNaCl is a good start and much more in the vein of an open web that isn't tied to a particular platform. And whatever benefits an Open Web, Mozilla will inevitably support, as it sustains their business model. NaCl doesn't do anything for browser makers, but it also doesn't help me as a user.
    - leoc 16y ago
      So what remaining problems with NaCl's compile-once-per-each-architecture model do you believe can't be solved by the combination of multi-architecture compilers (llvm, gcc ...) on the developer/server end and PNaCl on the client? Obviously the implementation is incomplete and immature, but Mozilla and Opera aren't even pretending that their opposition to NaCl is based on the immaturity of the implementation. > And whatever benefits an Open Web, Mozilla will inevitably support, as it sustains their business model. Mozilla inevitably supports and benefits from an Open Web only to the extent that you accept Mozilla's rather Newspeak definition of the Open Web as "a Web whose client API and runtime is under the shared control of a small group of browser vendors". If you have a less Orwellian kind of openness in mind, then it's clearly not true: Mozilla benefits from its shared control over the Web platform in largely the same way that MS benefits from its control over the Windows platform, and just like MS it has a strong self-interest in not seeing its platform "commoditised". As if that weren't perfectly clear already, then Chromeless underlines it. I assume you accept that Mozilla has a self-interest in seeing Chromeless succeed? The reason that Chromeless has a chance of hitting the big-time on the desktop is almost solely because Javascript and friends are popular on the Web client, and the ultimate reason for that is because JS and friends are bolted in and difficult to avoid on the web client.
      - bzbarsky 16y ago
        Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked. It's not as arhictecture-dependent as assembly but the last time I looked you couldn't generate the same LLVM on x86 and x86-64, say. Has that changed? It looks like PNaCl aims to "solve" this problem by using 32-bit-targeted LLVM... including 32-bit pointer alignment. It's not immediately obvious how portable this would be to some hardware, and more importantly I'm not aware of any plans to support anything other than x86 and ARM initially (well, and x86-64 using its ability to run 32-bit code as far as I can tell). Am I just missing something on this front? If I'm not missing anything, then this project's main impact if it caught on would be to restrict the set of hardware on which you can access web content, which is NOT a good thing.

lloydhilaiel 16y ago

one way you can do native code integration with chromeless is using JSCtypes: https://wiki.mozilla.org/JSctypes https://wiki.mozilla.org/JSctypes I hacked up a trivial proof of concept on this branch: https://github.com/mozilla/chromeless/tree/jsctypes_play https://github.com/mozilla/chromeless/tree/jsctypes_play

parbo 16y ago
Does JSCtypes allow for js functions to be used as C callbacks, like Python's ctypes does?