NPAPI: differenze tra le versioni

Versione delle 20:23, 13 dic 2019

Versione attuale delle 14:41, 6 ott 2024

(8 versioni intermedie di 7 utenti non mostrate)

Riga 1:

La '''NPAPI''' (''Netscape Plugin Application Programming Interface'') è un'architettura [[multipiattaforma]] per i [[plugin (informatica)|plugin]] utilizzata da molti [[browser web]]. Sviluppata inizialmente per la famiglia di browser [[Netscape Communications Corporation|Netscape]], a partire da [[Netscape Navigator]] 2.0, è stata implementata in seguito in altri browser, tra cui [[Mozilla Application Suite]], [[Mozilla Firefox]], [[Google Chrome|Chrome]], [[Safari (browser)|Safari]], [[Opera (browser)|Opera]], [[Konqueror]] e alcune versioni di [[Microsoft]] [[Internet Explorer]]. L'architettura è in via di [[obsolescenza]] e i browser più comuni hanno smesso di supportarla.

== Storia ==

L'origine della funzionalità dei plugin Netscape va ricercata non in [[Netscape Communications Corporation|Netscape]], ma in [[Adobe Systems(azienda)|Adobe]]. [[John Warnock]], [[amministratore delegato]] di Adobe, e [[Allan Padget]], uno dei principali autori di [[Acrobat Reader]], speravano che il formato di file di punta di Adobe, [[Portable Document Format|PDF]], potesse espandere la propria sfera d'uso ben oltre l'ambito desktop.

Perciò, poco tempo dopo il rilascio della prima versione di Navigator da parte di Netscape, Padgett, insieme all'ingegner Eshwar Priyadrshan, tentò di trovare un modo per rendere PDF parte integrante dell'esperienza del Web. Il risultato fu un'applicazione dimostrativa mostrata a Warnock e a [[James H. Clark|Jim Clark]], amministratore delegato di Netscape. Prima di quel demo, gli unici formati nativi sul Web erano le pagine [[HTML]] e le immagini mostrate al loro interno. I collegamenti a ogni altro tipo di file comportavano la richiesta all'utente di scaricare il file: fatto ciò, l'utente poteva aprire il file con l'applicazione più appropriata. In quella dimostrazione, tuttavia, quando un utente faceva click su un collegamento a un file PDF, il file veniva aperto immediatamente all'interno della finestra del browser, mescolando indifferentemente la fruizione di pagine HTML e documenti PDF. Clark chiese con eccitazione chi di Netscape avesse fornito supporto tecnico per rendere possibile l'integrazione, ma scoprì che essa era stata raggiunta senza il coinvolgimento di Netscape, ma con un po' di [[reverse engineering]] del browser.

Riga 25:

LiveConnect si rivelò estremamente problematico per Mozilla. La dipendenza da un runtime Java obsoleto e proprietario e dall'API JRI implicava l'impossibilità per LiveConnect di funzionare.

Mozilla stava già utilizzando [[XPCOM]] per definire le interfacce a molti oggetti implementati in C++. Ogni interfaccia veniva definita tramite un file [[Interface Description Language|IDL]] (Interface Definition Language), e passata a un compilatore IDL che produceva file d'intestazione e una libreria indipendente dal [[linguaggio di programmazione]] che costituiva la rappresentazione binaria dell'interfaccia: quest'ultima descriveva l'interfaccia, i metodi, i parametri, le strutture dati e le enumerazioni.

[[XPCOM]] usa le informazioni sul tipo di libreria per regolamentare le chiamate tra diversi contesti di thread e tra JavaScript codice nativo C++ compilato. Dal momento che XPConnect viene utilizzato pesantemente da Mozilla, è molto robusto, supportato e documentato. A partire da Netscape 6.1 e Mozilla 0.9.2, la NPAPI è stata estesa in modo tale che un plugin potesse restituire un'interfaccia a se stesso gestibile tramite script, mentre XPConnect si occupa di gestire le chiamate a detto plugin da JavaScript e dal codice C++.

Riga 31:

Ciò rese non più necessaria la dipendenza da Java, ma provocò alcuni problemi. In particolare, poiché l'implementazione viene effettuata utilizzando componenti XPCOM, una tecnologia simile a [[Component Object Model|Microsoft COM]], lo sviluppatore del plugin deve saper gestire il reference counting, le interfacce, l'IDL e così via per poter implementare lo scripting. Inoltre, la dipendenza da XPCOM comportava alcuni problemi nel collegamento dinamico delle librerie (ad esempio il problema della [[classe base fragile]]) che dovevano essere risolti per permettere al plugin di funzionare correttamente con browser differenti. XPCOM è stato in seguito modificato in modo tale da fornire una versione collegata staticamente per risolvere tali problemi. Quest'approccio richiede anche l'installazione di un file. xpt nella stessa locazione scelta per la DLL, altrimenti il plugin sembrerà funzionare, mentre la funzionalità di scripting non sarà disponibile.

=== NpruntimeNPRuntime ===

Alla fine del 2004, tutti i maggiori sviluppatori di browser (eccetto [[Microsoft]]) scelsero congiuntamente [https://www.mozilla.org/projects/plugins/npruntime.html npruntime] come estensione alla NPAPI originaria per fornire funzionalità di scripting, tramite un'API simile alla vecchia API stile C, e indipendente da altre tecnologie quali Java o XPCOM.

Riga 83:

A partire da maggio 2010 il [[browser]] [[open source]] di [[Google]], [[Chromium]], è l'unico browser che supporta il nuovo modello di plugin '''PPAPI'''<ref>[https://www.theregister.co.uk/2010/05/13/google_native_client_sdk/ Google heats up native code for Chrome OS]</ref>, [[Mozilla]] ha annunciato di "non essere interessata a implementare la tecnologia PPAPI al momento"<ref>[https://wiki.mozilla.org/NPAPI:Pepper NPAPI:Pepper - MozillaWiki]</ref>.

Nel febbraio del 2012, [[Adobe Systems(azienda)|Adobe]] ha annunciato che le future versioni di [[Flash Player]] sulla piattaforma [[Linux]] verranno fornite solo tramite questa API, anche se la versione Flash Player 11.2, con il supporto NPAPI, riceverà aggiornamenti di sicurezza per cinque anni<ref>{{Cita web |url=https://blogs.adobe.com/flashplayer/2012/02/adobe-and-google-partnering-for-flash-player-on-linux.html |titolo=Adobe and Google Partnering for Flash Player on Linux « Adobe AIR and Adobe Flash Player Team Blog<!-- Titolo generato automaticamente --> |accesso=3 maggio 2019 |urlarchivio=https://web.archive.org/web/20190519130745/http://blogs.adobe.com/flashplayer/2012/02/adobe-and-google-partnering-for-flash-player-on-linux.html |dataarchivio=19 maggio 2019 |urlmorto=sì }}</ref>. Successivamente, gli sviluppatori di Google hanno rivelato che a partire dalla versione 42 di Chrome i plugin NPAPI non verranno attivati per default (sebbene sarà comunque possibile forzarne l'utilizzo dalla pagina di impostazioni ''chrome://flags''), mentre dalla versione 45 non saranno più supportati<ref>[https://www.chromium.org/developers/npapi-deprecation NPAPI Depreation on chromium.org]</ref><ref>[https://support.google.com/chrome/answer/6213033# Informazioni sulla rimozione dei plugin NPAPI su support.google.com]</ref>.

== Plugin più utilizzati ==

* [[Adobe Acrobat Connect|Adobe Acrobat]]

* [[Adobe Shockwave]]

* [[Adobe Flash Player]]

Riga 105:

* {{en}} [https://www.mozilla.org/projects/plugins/plugin-host-control.html Un controllo ActiveX che offre supporto per i plugin] – Componente sostituivo per plugin.ocx, che è stato rimosso da Internet Explorer.

* {{cita web|url=http://news.com.com/IE+competitors+mull+ActiveX+alternative/2100-1032_3-5253504.html?tag=nl|titolo=I rivali di IE sostengono un'alternativa ad ActiveX – CNET|lingua=en|urlmorto=sì|urlarchivio=https://web.archive.org/web/20130308014956/http://news.com.com/IE+competitors+mull+ActiveX+alternative/2100-1032_3-5253504.html?tag=nl|dataarchivio=8 marzo 2013}}

{{Interfacce web}}

{{Portale|internet|telematica}}