NPAPI: differenze tra le versioni

Versione delle 19:39, 17 feb 2016

Versione delle 13:14, 13 mag 2016

Riga 29:

[[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++.

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.

=== Npruntime ===

Riga 45:

Un controllo veniva implementato da una DLL, e caricato nello spazio degli indirizzi del contenitore ospite, come ad esempio [[Visual Basic]]. Le prime versioni di Visual Basic utilizzavano una tecnologia simile chiamata [[Visual Basic Extension]], ma i controlli OCX vennero considerati migliori. Ogni OCX implementava un sottoinsieme ben definito delle interfacce OLE2 che il contenitore poteva usare per manipolare il controllo, ad esempio per spostarlo, o per fornire informazioni sul contenitore. L'OCX implementava anche un ''meccanismo di automazione'' che permetteva la pubblicazione di metodi e proprietà che potevano essere modificati, e utilizzava un metodo complementare per restituire degli eventi al contenitore.

OLE2 era molto complicato, e il suo supporto nelle [[Microsoft Foundation Classes|MFC]] era minimo, perciò Microsoft razionalizzò la specifica in modo da semplificarla, e ridenominò la tecnologia in [[ActiveX]]. Anche dopo la semplificazione i controlli richiedevano necessariamente che all'incirca 6 interfacce fondamentali venissero implementate. Microsoft, per allievarealleviare questa complessità, produsse dei wizard, delle classi base ATL, delle macro e delle estensioni al linguaggio [[C++]] per semplificare la scrittura di controlli.

A partire da Internet Explorer 3.0 venne aggiunta la possibilità di ospitare controlli ActiveX all'interno di contenuto HTML. Se il browser elaborava una pagina che specificava un controllo ActiveX attraverso un tag OBJECT (e una sintassi non accettata dal [[W3C]]), avrebbe scaricato automaticamente e installato il controllo, con intervento minimo, se non nullo, dell'utente. Ciò rese la fruizione del web "più ricca", ma venne percepita come limitante (dal momento che i controlli funzionavano solo su Windows) e come un rischio per la sicurezza, a causa del mancato intervento dell'utente. Microsoft è stata costretta a introdurre delle misure di sicurezza per porre rimedio alle proprie mancanze. Ad esempio: