NPAPI: differenze tra le versioni

Versione delle 23:01, 9 ago 2007

Versione delle 23:24, 9 ago 2007

Riga 1:

La ''NPAPI'' (o ''Netscape Plugin Application Programming Interface''') è un architettura [[multipiattaforma]] per i [[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]], [[Safari (browser)|Safari]], [[Opera (browser)|Opera]], [[Konqueror]] ed alcune versioni di [[Microsoft]] [[Internet Explorer]].

Il suo successo può essere in parte attribuito alla sua semplicità. Un plugin dichiara di gestire alcuni tipi [[MIME]] (ad esempio "audio/mp3") mediante le informazioni sui file presentati. Quando il browser incontra tale tipo di contenuti carica il plugin associato, delimita lo spazio all'interno dell'area di visualizzazione da assegnare al plugin, e infine vi trasferisce dati. Al plugin viene, quindi, assegnato il compito di gestire i dati nel modo più opportuno, sia esso visivo, audio o qualunque altra cosa. In questo modo, un plugin viene eseguito nella propria parte di pagina, a differenza dei browser precedenti, che dovevano lanciare un'applicazione esterna per gestire i tipi di contenuto a loro ignoti.

Riga 13:

Le aziende stabilirono di incontrarsi la settimana successiva per trovare il modo di rendere appetibile quello che era conosciuto come "l'hack di Allan" per il mercato. Sebbene Netscape fosse pronta ad incorporare i PDF direttamente all'interno del browser, e certamente Adobe ne avrebbe guadagnato, Padgett propose un approccio diverso: un'architettura basata sui plugin. Gli ingegneri Adobe Gordon Dow e Nabeel Al-Shamma avevano da poco aggiunto un'architettura a plugin ad Acrobat Reader, per ridurre gli sforzi degli sviluppatori di terze parti. Padgett aveva partecipato allo sviluppo, e riteneva che se si fosse fornita l'occasione, altre aziende (e magari altri team all'interno di Adobe) avrebbero scelto di estendere le capacità del Web. Clark ed il team alla fine si convinsero, e cominciarono a disegnare l'API che avrebbe dovuto supportare il nuovo modello di sviluppo. Sebbene PDF sia stato il pioniere, si potrebbe affermare che plugin successivi, quali [[Macromedia Flash]] e [[Java]], abbiano inciso molto di più sul panorama del web.

== Supporto agli script ==

<!--

== Scripting support ==

PluginLa scriptabilitypossibilità isdi aaggiungere featuredegli allowingscript ai plugin è una caratteristica che permette al codice JavaScript codepresente in auna webpagina pagedi tointeragire interactcon with theun plugin. VariousDiverse versionsversioni ofdi Netscape, ed in andseguito thendi Mozilla, supportedhanno thissupportato featurequesta usingcaratteristica differentutilizzando technologiestecnologie fra loro differenti: LiveConnect, XPConnect, ande npruntime.

=== LiveConnect ===

With Netscape 4, the NPAPI was extended to allow plugins to be scripted. This ability was known as [[LiveConnect]]. A plugin could implement and return an instance to a [[Java (programming language)|Java]] class. The public methods exposed by this class was the scriptable interface for the plugin. The class could be called from [[JavaScript]] and even from other Java applets running within the page with the browser marshalling the calls between the various contexts.

Con Netscape 4, la NPAPI venne estesa per permettere di sfruttare i plugin tramite degli script. Questa funzionalità venne chiamata [[LiveConnect]]. Un plugin poteva implementare e restituire un'istanza di una classe [[Java]]. I metodi pubblici esposti da questa classe rappresentavano l'interfaccia cui potevano essere applicati degli script. La classe poteva essere chiamata tramite codice [[JavaScript]], come anche da altre applet Java in esecuzione all'interno della pagina, mentre il browser vigilava sulle chiamate tra i diversi

The disadvantage of LiveConnect was that it was tied heavily to the built-in version of Java within the Netscape browser. This prevented the browser from using other Java runtimes, and added a massive amount of bloat to the browser download size since it required Java to script plugins.

contesti d'esecuzione.

Lo svantaggio di LiveConnect risiedeva nell'essere legato a doppio filo con la versione di Java integrata all'interno del browsr Netscape. Ciò impediva al browser di utilizzare altri runtime, ed appesantiva significativamente il download del browser, dal momento che Java era un componente fondamentale per lo scripting dei plugin.

Additionally, LiveConnect was tricky to program. The developer had to define a Java class for the plugin, run it through a specialised Java header compiler and implement the native methods. Handling strings, exceptions and other Java objects from [[C++]] was fraught and non-obvious. To compound matters LiveConnect used an earlier and now obsolete API for invoking native C++ calls from Java called JRI. The JRI technology has long been supplanted by [[Java Native Interface|JNI]].

Inoltre, la programmazione di LiveConnect non era affatto immediata. Lo sviluppatore doveva definire una classe Java per il plugin, eseguirla tramite un compilatore di intestazioni Java specializzato ed implementare i metodi nativi. La gestione delle stringhe, delle eccezioni e degli altri oggetti Java dal [[C++]] era frustrante e certamente non lapalissiana. A peggiorare le cose era il fatto che LiveConnect utilizzava un'API adesso obsoleta per invocare metodi C++ nativi da Java, chiamato JRI. La tecnologia JRI è stata da tempo sostituita dalla [[Java Native Interface|JNI]].

<!--

=== XPConnect ===

LiveConnect proved extremely problematic for Mozilla. The dependency on an obsolete and proprietary Java runtime and the JRI API meant that LiveConnect never really worked.