Icedtea supports something called "Pepper"?
Adam Domurad
domuradical at gmail.com
Tue Jul 15 16:05:11 UTC 2014
On Tue, Jul 15, 2014 at 2:39 PM, Jiri Vanek <jvanek at redhat.com> wrote:
>
> On 06/10/2014 03:57 AM, Adam Domurad wrote:
>>
>> helpcrypto helpcrypto <helpcrypto at ...> writes:
>>
>>>
>>>
>>>
>>>
>>>
>>> Hi all.
>>> Last days I have seen a couple of sources claiming (Google) Chrome and
>>
>> (Mozilla) Firefox are going to abandon NPAPI and start using Peeper plugins.
>>
>> No. Google Chrome is abandoning NPAPI in favour of Google Native Client --
>> something *very* different in philosophy. Flash is currently the sole
>> *special exception* that is allowed to use PPAPI (Pepper)!
>>
>> I repeat: Supporting PPAPI will *not* help icedtea-web run on
>> Chrome/Chromium unless icedtea-web also has this special exceptional
>> treatment! This is possible by patching Chromium I presume -- but,
>> unfortunately, not a trivial matter.
>
>
> Hi Adam!
>
> Where you got this impression.
>
> I made some digging and it seems that PPAPI is,and wil remain in chrome/chromium
> I also checked the api - https://developer.chrome.com/native-client/pepper_stable/ - which is proclaimed as stbale. And it looks quite ok.
>
> If FireBreath api is running both under NPAPI and PAPER api, it would be the good way then.
Native client has the same sandbox as a Javascript client. Google
allows PPAPI plugins that aren't in this sandbox, but must be
selectively installed, and is generally not feasible for icedtea-web.
Furthermore, I do not think FireBreath API supports Pepper/PPAPI, for
example, check out
http://www.firebreath.org/display/documentation/Browser+Plugins+in+a+post-NPAPI+world
They claim:
"We have confirmed that PPAPI will not work because while Chrome
supports it they don't provide any way for third parties to install
PPAPI plugins. The only method of doing so involves a command-line
argument, which is unsuitable for most purposes."
If everything that icedtea-web needs is available in Google Native
Client then maybe it is OK, but I have not got this impression.
Unfortunately, as icedtea-web maintainer, I must return the burden of
proof on you.
Relaxing in Poland,
-Adam
> J
>
>>
>>> Is Icetea "ready" for that possible change?
>>
>>
>> Since we're being clear -- icedtea is a polite way of saying 'Java'; there
>> is nothing wrong with Icedtea. *icedtea-web* is not ready for this change --
>> but that is simply because no NPAPI plugin is.
>>
>>> Will all my applets fail to work next year? (as they are doing with latest
>>
>> Oracle releases)
>>
>> Sadly -- yes, they will fail. As far as I can see, Google Chrome simply does
>> not want to plugins to interact with the operating system, even under the
>> new 'Google Native Client' plugin architecture. Oracle may be more lucky
>> (re: special treatment like Flash).
>>
>> Check out https://developer.chrome.com/native-client/faq ->
>>
>> "If I want direct access to the OS, should I use Native Client?
>>
>> No—Native Client does not provide direct access to the OS or devices, or
>> otherwise bypass the JavaScript security model. For more information, see
>> later sections of this FAQ.
>> "
>>
>> I might have taken this up if it was a 'simple' matter of a NPAPI <-> PPAPI
>> bridge (such things do exist, at least in part, from some google-work). But
>> it's a bit hopeless with Google Native Client. At least -- it needs serious
>> thought and work.
>>
>>> Thanks for the info!
>>>
>>
>> Happy hacking,
>> -Adam
>>
>
More information about the distro-pkg-dev
mailing list