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
