On Sunday, August 14, 2011 3:29:28 PM, Marco Leise wrote: > Am 14.08.2011, 22:00 Uhr, schrieb Andrew Wiley <wiley.andre...@gmail.com>: > >> On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise <marco.le...@gmx.de> wrote: >> >>> Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley <wiley.andre...@gmail.com>: >>> >>> On Sat, Aug 13, 2011 at 5:10 AM, bearophile <bearophileh...@lycos.com>** >>>> wrote: >>>> >>>> Found though Reddit. It seems Chrome is starting to warm up to the Native >>>>> Client (NaCl) idea, the Chrome Beta now has a working NaCl: >>>>> >>>>> http://chrome.blogspot.com/**2011/08/building-better-web-** >>>>> apps-with-new.html<http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html> >>>>> >>>>> >>>>> http://channel9.msdn.com/**Shows/C9-GoingNative/** >>>>> GoingNative-0-Help-us-fly-**this-plane-Some-modern-C-Meet-**Ale-Contenti<http://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-0-Help-us-fly-this-plane-Some-modern-C-Meet-Ale-Contenti> >>>>> >>>>>
>>>>> It's one (the only?) chance to use D in the browser. >>>>> >>>>> Bye, >>>>> bearophile >>>>> >>>>> >>>> Just thought I'd point out that the previous discussions on NaCl seem to >>>> have missed this part of the overview: >>>> "The Pepper Plug-in API (PPAPI), called *Pepper* for convenience, is >>>> included in the Native Client SDK. This library is written in C, and the >>>> SDK >>>> also provides a set of C++ bindings for it. Native Client modules use the >>>> Pepper API to communicate with the browser's JavaScript, the DOM, and >>>> other >>>> resources managed by the browser. The Pepper Library also provides a >>>> platform-independent multimedia API that Native Client modules can use for >>>> audio, video, and 2D graphics." >>>> >>>> So yes, this is somewhat geared toward multimedia, but it looks like it >>>> can >>>> also replace javascript in web apps. >>>> >>> >>> Is this basically the same as the Java applet interface to the browser >>> without the "compile once , run everywhere", but with better API? >>> >> >> I haven't ever dealt with the applet interface, but that quote came from >> http://code.google.com/chrome/nativeclient/docs/technical_overview.html if >> you want to take a closer look. The Pepper API docs are there as well. > > It doesn't convince me. The driving force seems to be moving desktop > applications into the browser. That's > understandable since a lot of people at Google use their web services where > possible. I personally don't like that > centralization on the browser. It adds up on complexity and bugs, trying to > be an operating system that manages running > applications. How do they make sure the code is safer than what we know from > ActiveX? Even the WebGL standard was in the > critics, because it was obviously accessing the gfx card and a malicious > texture upload in a buggy driver could become a > security risk. > Maybe it finds a way through good advertising or real-time games which run > faster with native code instead of > JavaScript, but there will always be some bad memories from > http://www.adoko.com/activex.html > At least they take the issue serious :) > http://www.zdnet.com/blog/security/google-wants-to-buy-native-client-security-flaws/2702 Quite frankly, it's too late to pretend that the web and the browser is all there is for a large segment of the computer and 'net using population. They never leave the browser. That's only going to grow. Pretending otherwise, is, well, fairly pointless. The people on this are in a very small minority and do NOT represent the typical user. Haven't for a long time. Sorry Nick. Later, Brad
