mardi 30 juin

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

[10] Collabtive - Application de gestion de projet collaborative
[64] Le noyau Linux 2.6.28 est disponible
[6] Quantum GIS 1.0
[42] Gajim 0.12... enfin
[2] iStoa.net v. 8.12-alpha1
[8] Yo Frankie! le jeu
[5] GnoFract 4D - Générateur de Fractale
[14] Centreon 2.0 est sortie en version finale
[7] Sortie de GDAL/OGR 1.6.0
[42] PepperSpot, Portail Captif nouvelle génération

Liens connexes

Page du projet (462 hits)
Annonce détaillée (198 hits)
Migration transparente d'applications vers des appareils mobiles sous Linux (214 hits)

Dépêche modérée par

pterjan

Dépêche éditée par

Logiciel : nspluginwrapper 1.2.0

Posté par Gwenole Beauchesne (page perso, ). Modéré le 26 décembre 2008.

nspluginwrapper est maintenant disponible en version 1.2.0. nspluginwrapper est une solution qui permet d'exécuter des greffons NPAPI en dehors d'un navigateur Internet, tout en maintenant un lien avec celui-ci. Ainsi, il permet par exemple d'exécuter les greffons propriétaires Flash Player, initialement prévus pour i386, dans un navigateur web compilé pour x86_64. Nous allons voir d'autres usages par la suite.

Page du projet (462 hits)
Annonce détaillée (198 hits)
Migration transparente d'applications vers des appareils mobiles sous Linux (214 hits)

> Lire la suite (9 commentaires, moyenne: 3,7). [dépêche : 3536 caractères]

Voici un condensé des modifications apportées pendant la phase de développement (versions 1.1.x).

Gestion des greffons en mode windowless. Vous avez sans doute remarqué que les greffons s'exécutaient dans une fenêtre séparée, mais intégrée dans la hiérarchie de fenêtres du navigateur. De ce fait, les menus déroulants pouvaient parfois s'afficher en dessous de la fenêtre du greffon. Eh bien, Firefox 3 autorise à présent les greffons qui le supportent à dessiner dans une pixmap. On appelle cela le mode windowless. En pratique, il s'agit typiquement de Flash 10 et Gnash un peu aussi maintenant. nspluginwrapper s'aligne sur le support du navigateur.

Greffons natifs. Vous avez sans doute entendu parler de Google Chrome et de son architecture multi-processus et de confinement. L'idée n'est pas neuve, et Red Hat l'implémentait déjà depuis quelques temps avec l'aide de nspluginwrapper. Vu que nspluginwrapper est un processus indépendant, l'intérêt est triple :

Si le greffon se vautre (crash), il n'emporte pas tout le navigateur avec lui. Ainsi, le navigateur survit et il suffit de recharger la page incriminée. Pour l'instant, le greffon n'est pas rejoué, i.e. il ne redémarre pas tout seul, il faut que ce soit une action motivée par l'utilisateur.
Si le greffon est un goinfre de mémoire mais qu'il la digère mal, alors les fuites de mémoire sont limitées à ce processus, et non au niveau du navigateur qui vit plus longtemps. Rappel : s'il n'existe plus aucune instance d'un greffon donné, alors il est dé-initialisé. Cela correspond à l'arrêt normal du processus nspluginwrapper, et ainsi de toute la mémoire non-partagée qui y était créée.
Mesures de sécurité. Il est possible d'autoriser le greffon à n'accéder qu'à certaines ressources. e.g. connexion aux ports HTTP uniquement, interdiction de lire certains fichiers dits sensibles comme /etc/shadow, etc. Tout ceci se contrôle avec des règles SELinux, ou RSBAC. nspluginwrapper ne fournit aucune politique de sécurité, cela échoit au distributeur.

Lecteur auto-suffisant de greffons. En fait, il s'agit d'une petite application (nspluginplayer) qui permet d'exécuter des greffons sans navigateur web. C'est assez utile si l'on veut par exemple exécuter une pauvre animation Flash sur un stand,... ou de déboguer un greffon. Bon, ça ne supporte pas l'intégralité de NPAPI mais c'est tout à fait suffisant pour exécuter Flash Player et le greffon d'Adobe Reader. La syntaxe de nspluginplayer peut sembler compliquée, mais il suffit en fait de lui fournir les arguments de la balise embed.

Par exemple, pour jouer à Magic Paint, on lancera la commande:

$ nspluginplayer src=<a href="http://magic.pen.fizzlebot.com/magic-pen.swf">http://magic.pen.fizzlebot.com/magic-pen.swf</a> width=800 height=520

Prise en charge de nouvelles architectures et systèmes. nspluginwrapper tourne maintenant sous OpenSolaris 2008.xx. Transitive Technologies l'utilise notamment pour exécuter le greffon Adobe Reader, qui n'existe que pour Solaris/SPARC. Encore plus intéressant, ils utilisent nspluginwrapper pour exécuter le greffon Flash 9 Linux/i386 sur Linux/ARM.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Merci

Posté par Zorro () le 26/12/2008 à 23:24. (lien). Évalué à 4.

Je voulais juste te dire merci et bravo pour ton logiciel, qui m'a rendu de fiers services du temps de Flash 9 et 10 32 bits.

[^]Re: Merci

Posté par uıpɹɐʌɹɐɟ (page perso, ) le 27/12/2008 à 11:42. (lien). Évalué à 3.
effectivement, je vois aussi que tu as contribué à des projets particulièrement audacieux (emulateur powerpc etc), félicitations et merci Gwenolé !

--
"C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard"
---------
Les dalles brillantes c'est moche et nul

mem leak

Posté par fcartegnie () le 27/12/2008 à 00:08. (lien). Évalué à 2.

Mais gros problème de fuite mémoire avec Acrobat reader sur amd64 depuis la version 0.9 :(

[^]Re: mem leak

Posté par Gwenole Beauchesne (page perso, ) le 27/12/2008 à 01:13. (lien). Évalué à 9.
Euh, oui, il y avait des fuites de mémoire dans le bridge NPRuntime jusqu'à la version 1.1.6. Je ne sais pas si c'est ton problème en particulier, mais c'est ce que j'avais remarqué lors de ma phase de review du code.

Si tu suspectes encore des fuites de mémoire dans la version 1.2.0, il est également possible de ne lancer valgrind que sur nspluginwrapper, et donc les plug-ins, i.e. on ne s'embête pas à valgrind'er sur tout le browser. Pour ce faire, démarre juste le browser en le préfixant de la variable NPW_USE_VALGRIND=yes.

Par exemple:$ NPW_USE_VALGRIND=yes NPW_VALGRIND_OPTIONS="--leak-check=full" firefox file:///path/to/file.pdf 2>&1|tee l
Ca fait un peu fonctionnalité secrète mais a priori ce n'était utile que pour moi. ;-) Ah oui, si tu vois une tripotée de variables utilisées avant d'être initialisées, t'en fais pas, c'est "normal" pour les plug-ins d'Adobe, ou bien est-ce valgrind qui ne détecte pas bien ces cas?

et java

Posté par Matthieu C () le 27/12/2008 à 18:32. (lien). Évalué à 2.

Est ce que ça marche avec java ? Il n'est pas listé sur la page du projet

[^]Re: et java

Posté par Gwenole Beauchesne (page perso, ) le 27/12/2008 à 21:02. (lien). Évalué à 3.
Non, les plug-ins Java ne sont pas supportés. Ceux utilisant l'API OJI ne le seront jamais, a priori. En théorie, il devrait être possible de supporter le nouveau plug-in Java de Sun, qui utilise NPAPI et NPRuntime. En pratique, c'est un peu plus complexe car il semble exister encore des bouts de XPCOM dedans, ce qui n'est pas supporté. Quant au plug-in Java d'IcedTea, je n'ai pas encore regardé mais (i) il exécute déjà l'appletviewer dans un autre processus me semble-t-il, et (ii) il est disponible nativement.

Des plugins i386 sur un i386

Posté par baptiste1ch () le 28/12/2008 à 14:21. (lien). Évalué à 1.

Est il possible d 'utiliser nspluginwrapper sur du i386, pour éxécuter des plugins i386?

Vu les avantages de la description, notament pour la gestion des crashs et de la consommation.

Merci.

[^]Re: Des plugins i386 sur un i386

Posté par Pascal Terjan (Jabber id, page perso, ) le 29/12/2008 à 09:30. (lien). Évalué à 6.
Oui (c'est d'ailleurs maintenant par défaut sur Mandriva)

nspluginwrapper 1.2.2

Posté par Gwenole Beauchesne (page perso, ) le 02/01/2009 à 11:33. (lien). Évalué à 3.

Une nouvelle version de maintenance vient d'être publiée:
* Correction du support du plug-in VLC (0.8.6)
* Correction d'un problème de déallocation mémoire dans NPN_GetStringIdentifiers() pouvant causer un crash du navigateur
* Correction d'un cas d'erreur lors de la création de flux dans le lecteur autonome

Revenir en haut de page