NPAPI: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Gsdefender2 (discussione | contributi)
mNessun oggetto della modifica
Gsdefender2 (discussione | contributi)
Nessun oggetto della modifica
Riga 3:
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.
 
L'[[application programming interface|API]] richiede che ogni plugin implementi e pubblichi un numero abbastanza piccolo di funzioni. Si tratta approsimativamente 15 funzioni in totale per l'inizializzazione, la creazione, la distruzione e il posizionamento dei plugin. La NPAPI supporta anche lo scripting, la stampa, la visualizzazione a schermo intero, i plugin ''windowless'' e lo [[streaming]] dei contenuti.
<!--
Its success can be partly attributed to its simplicity. A plugin declares that it handles certain [[MIME|content types]] (e.g. "audio/mp3") through exposed file information. When the browser encounters such content type it loads the associated plugin, sets aside the space within the browser content for the plugin to render itself and then streams data to it. The plugin is then responsible for rendering the data as it sees fit, be it visual, audio or otherwise. So a plugin runs in-place within the page, as opposed to older browsers that had to launch an external application to handle unknown content types.
 
== HistoryStoria ==
The [[application programming interface|API]] requires each plugin to implement and expose a comparatively small number of functions. There are approximately 15 functions in total for initialising, creating, destroying, and positioning plugins. The NPAPI also supports scripting, printing, full screen plugins, windowless plugins and content streaming.
 
TheL'origine origindella offunzionalità the Netscapedei plugin functionalityNetscape va startedricercata notnon withinin [[Netscape Communications Corporation|Netscape]], butma atin [[Adobe Systems]]. [[John Warnock]], [[Chiefamministratore executive officer|CEOdelegato]] ofdi Adobe, anded [[Allan PadgettPadget]], oneuno ofdei theprincipali primaryautori authors of thedi [[Acrobat Reader]], weresperavano hopefulche thatil Adobe'sformato fledglingdi file di punta di Adobe, [[Portable Document Format|PDF]], file formatpotesse couldespandere playla apropria rolesfera beyondd'uso theben oltre l'ambito desktop.
== History ==
The origin of the Netscape plugin functionality started not within [[Netscape Communications Corporation|Netscape]], but at [[Adobe Systems]]. [[John Warnock]], [[Chief executive officer|CEO]] of Adobe, and [[Allan Padgett]], one of the primary authors of the [[Acrobat Reader]], were hopeful that Adobe's fledgling [[Portable Document Format|PDF]] file format could play a role beyond the desktop.
 
<!--
== History ==
Therefore, soon after Netscape released the first version of Navigator, Padgett and fellow engineer Eshwar Priyadarshan tried to find a way to make PDF an integral part of the Web experience. The result was a live demo shown to Warnock and [[Jim Clark]], the CEO of Netscape. Prior to that demo, the only native file formats on the Web were [[HTML]] pages and the images embedded within them. Links to any other file type caused the user to be prompted to download the file, after which the user could open the file in the appropriate application. In that demo, however, when a user clicked on a link to a PDF file, the file was instantly opened within the browser window, seamlessly blending HTML and PDF consumption. Clark excitedly asked who at Netscape had provided support for the integration, only to discover that the integration was done without Netscape involvement, but with a bit of [[reverse engineering]] of the Netscape browser.