Cos'è l'"architettura" che fornisce funzionalità alle interfacce URI a livello di applicazione, come chrome: // e Firefox riguardo a: config, ecc.?

Naviga le tue risposte
4

Secondo Wikipedia ,

about is an internal URI scheme (also known as a "URL scheme" or, erroneously, "protocol") in various web browsers to display certain built-in functions. It is not an officially registered scheme, and has no standard syntax.

la mia domanda è ... che cosa "alimenta" queste "interfacce"? sembra che non ci sia alcun tipo di "application server" in esecuzione, che avrebbe convenzionalmente supportato tale front-end - se fosse in esecuzione da remoto .. sono sicuro che il motivo della mancanza di informazioni là fuori - è che tutto ciò interrompe psuedo-promise che qualsiasi cosa "fai" nel browser - non "farà" effetto sul tuo sistema. queste interfacce chiaramente hanno accesso a risorse e permessi a livello di sistema, ecc. sono tutti semplicemente ganci personalizzati, codificati in c, nel codice interno delle applicazioni madri - o sono più astratti, ui - strato ?

Ammetto di avere poca conoscenza della creazione di plug-in, ma questo tipo di funzionalità può essere ottenuto tramite le tipiche API plug-in o sono troppo limitate? Ho passato un po 'di tempo nel codice sorgente del webkit a dare un'occhiata - ma è così massiccio e contorto che è difficile dedurre molto ...

sembrerebbe che tuttavia questi venditori stiano implementando queste funzionalità potrebbe essere un'alternativa attraente per dire, i vari ponti specifici della lingua che il webkit implementa su varie piattaforme. Personalmente trovo i ponti frustranti, il che è probabilmente ciò che mi ha spinto a seguire questo ragionamento ...

qualsiasi informazione apprezzata.

    
posta alex gray 14.01.2012 - 22:31
fonte

4 risposte

5

Un browser moderno deve supportare un numero di diversi schemi URI, ad es. http: , ftp: , file: , data: , mailto: . La gestione può essere molto diversa a seconda dello schema, non si tratta sempre di comunicare con un server - data: ottiene i dati dall'URI stesso mentre mailto: semplicemente apre un'applicazione esterna (o a volte una pagina web ). Quindi AFAIK ogni browser utilizza diversi gestori di protocollo per ogni schema URI e questi gestori di protocollo possono fare praticamente tutto.

Il protocollo chrome: in Firefox è un modo per accedere al registro chrome . Il browser e le estensioni registrano la posizione dei loro "server" per i loro "server" chrome, queste posizioni sono o una directory su disco o una directory all'interno di un file JAR (tecnicamente: ZIP). Il gestore di protocollo utilizza i dati del registro per risolvere gli URI chrome: negli equivalenti file: e jar: URI. C'è un po 'di magia aggiuntiva legata al considerare la localizzazione / skin attuale, ma questo è tutto. Il duro lavoro (ottenendo effettivamente i dati) viene quindi eseguito dai gestori dei protocolli file: e jar: .

Anche il protocollo about: in Firefox non svolge alcun lavoro autonomamente. La parola che segue about: determina quale gestore deve utilizzare il gestore di protocollo. Cerca questo gestore in XPCOM e lascia che faccia il lavoro. La maggior parte dei gestori rimanderà di nuovo il lavoro ad altri protocolli: gli URI about: sono in genere solo scorciatoie. Ad esempio, about:config è semplicemente un alias per chrome://global/content/config.xul .

Spero che questo ti dia un'idea di come funzioni quest'architettura - non c'è un grosso gestore per ogni tipo di URI, il lavoro è piuttosto distribuito su molti componenti. XPCOM è la colla che tiene insieme questi componenti e fa in modo che i componenti possano entrare e uscire (ad es. Tramite le estensioni) senza che tutto si rompa.

    
risposta data 16.02.2012 - 14:41
fonte
2

about: non è nient'altro che un'istruzione if da qualche parte nel codice del browser - un caso speciale che fa tutto ciò che i programmatori di browser vogliono che faccia. Non c'è niente di speciale in questo.

Anche se l'attività principale di un browser è quella di eseguire il rendering di pagine Web, è ancora solo un'applicazione in grado di fare anche altre cose.

    
risposta data 15.01.2012 - 01:47
fonte
2

Come già detto in due precedenti risposte, quelle non sono schemi reali con hook di sistema, ma solo una funzione browser che risponde ad alcuni tipi di indirizzi.

Voglio solo aggiungere che c'è un modo semplice per capirlo:

  • Se si trattasse di uno schema reale o di un hook, funzionerebbe con qualsiasi browser .

    1. Apri Chrome.
    2. Apri Internet Explorer.
    3. Apri chrome://settings/ in IE.

    Viene visualizzato un 404 anziché le impostazioni di Chrome. Uno schema o un hook non ha lo scopo di comportarsi in questo modo: è previsto che funzioni per qualsiasi browser, mostrando qualcosa, come http:// , o reindirizzando l'utente a un'applicazione esterna, come ed2k:// , o mostrando un messaggio di errore, come unexistent:// .

  • Se era uno schema reale, sarebbe registrato . In Windows, ad esempio, ciò significa che ci sarebbe una chiave di registro in un luogo specifico per questo schema.

these all break the psuedo-promise that anything "you do" in the browser - won't "effect" your system. these interfaces clearly have access to system level resources and permissions

Che cosa ti fa pensare così? In Windows, uno schema URL è solo una chiave di registro. Se Chrome ha registrato lo schema chrome:// , una chiamata a chrome://hello/world chiamerebbe un'istanza di chrome.exe, superando hello/world come argomento. Sì, l'installazione di Chrome ha influito sul tuo sistema aggiungendo un'altra chiave di registro, ma qualsiasi installazione di qualsiasi software influisce sul tuo sistema. Il modello sandbox del browser rimane attivo: non è chiamando uno schema registrato per rompere qualcosa (beh, puoi, e per evitare ciò, i browser ti chiedono di confermare quello che stai facendo quando usi un nuovo schema per la prima volta).

    
risposta data 15.01.2012 - 11:26
fonte
1

La about:config di Firefox sembra essere una UI per la modifica del file prefs.js .

Esistono tre metodi: pref() , user_pref() e lock_pref() che possono essere utilizzati in JavaScript. Probabilmente non da JavaScript nelle pagine Web, per ovvi motivi di sicurezza, ma invece in XUL / pacchetti .XPI .

Al primo link sopra riportato:

Distributors can add default preference files via .XPI packages.

e assegna il codice install.js di esempio.

    
risposta data 15.01.2012 - 00:34
fonte

Leggi altre domande sui tag

Come l'Erlang diventa soft-realtime con GC? Cambiare da VB.NET a C #? [chiuso]