Les derniers billets

Je me suis intéressé récemment au projet weave de mozilla. Il s'agit principalement d'une extension Firefox qui permet la synchronisation de données (historique, marque-pages, etc) entre différents postes de travail.

Ce type d'outil est très répandu, mais le premier intérêt de weave, c'est que les données sont chiffrées avant envoi au serveur; il lui est donc impossible de lire nos données, de les diffuser ou de les revendre. Le deuxième intérêt, c'est qu'en plus de proposer le service de synchronisation, Mozilla met à disposition, sous licence libre, le logiciel du serveur de synchronisation. Il devient ainsi facile de synchroniser des profils Firefox de manière totalement indépendante, c'est à dire sans dépendre d'un service que l'on ne maitrise pas.

Pour cela, j'ai d'abord commencé par créer mon sous-domaine weave.renevier.net et attendu que les dns soient mis à jour. Ensuite, j'ai téléchargé une copie du minimal server. À priori il existe une version plus complète et plus compliquée à installer, mais le minimal server est adapté à un usage domestique pour lequel les nouveaux utilisateurs sont ajoutés manuellement.

J'ai ensuite décompressé l'archive
tar zxf weave_minimal.tgz
puis j'ai déplacé le répertoire extrait dans le répertoire de mon choix
mv weave_minimal /var/http/
J'ai ensuite donné les droits en écriture à l'utilisateur qui fait tourner le serveur web, afin que la base de données sqlite puisse être crée puis mise à jour correctement.
chgrp -R /var/http/weave && chmod g+w /var/http/weave
Weave a besoin d'une installation de php qui supporte json, mbstring et sqlite, j'ai donc du installer, sur mon serveur en debian stable, le paquet php5-sqlite
J'ai ensuite configuré et redémarré le serveur web. J'utilise lighttpd, voici le contenu de mon fichier de configuration

server.modules += ( "mod_alias", "mod_redirect", "mod_auth" )

$HTTP["host"] =~ "^weave.renevier.net$" {

    server.document-root = "/var/httpd/weave/"
    alias.url = ("/weave" => "/var/httpd/weave/index.php")

    $SERVER["socket"] == ":80" {
        url.redirect = ( "^/(.*)" => "https://weave.renevier.net/$1" )
    }

}

Pour que weave soit disponible en https, il faut créer un certificat. Idéalement, il faudrait le faire certifier par une autorité de certification, mais pour un usage personnel, un certificat auto-signé fait très bien l'affaire. Comme j'en avais déjà un, je n'ai pas eu à en recréer, je ne vais donc pas décrire cette étape, mais des bons tutoriels existent sur le web.

Ensuite, je me suis rendu avec mon navigateur à l'adresse https://weave.renevier.net/weave/1.0/blah/info/collection et mon navigateur m'a demandé login et mot de passe. On peut rentrer n'importe quoi, cette étape ne sert qu'à initialiser la base sqlite. Ensuite, le navigateur redemande en boucle login et mot de passe, c'est normal, il suffit juste de répondre une seule fois.

On peut maintenant créer les utilisateurs du service grâce au script create_user disponible dans le dossier weave: php create_user.

Il ne reste plus maintenant qu'à installer l'extension sur les postes de travail que l'on veut synchroniser. Avant d'installer l'extension, il m'a été nécessaire, vu que j'utilise un certificat autosigné, de visiter l'url https://weave.renevier.net/ afin d'ajouter une exception de sécurité pour chacun des postes que je vais synchroniser. Lors de la configuration de l'extension, j'ai du choisir l'option Use a custom server, et configurer l'url suivante: https://weave.renevier.net/weave/

Voila, weave est maintenant installé !

Comme expliqué dans un épisode précédent, après une dizaine d'années de fidélité aux autotools je suis récemment passé à CMake et l'essayer c'est l'adopter. Du coup, je me suis demandé si Okawix pourrait être construit avec ; et qui dit construire Okawix, dit compiler des composants XPCOM et la... pas de bol, CMake ne fournit pas de module pour faire du XPCOM. Enfin... pas encore :)

J'ai donc travaillé sur un module CMake permettant de détecter XUL ; en fait, sur plusieurs modules : un pour XUL lui même, un pour NSPR et un dernier module "utilitaire" qui fait une bonne partie du sale boulot. Ces modules sont maintenant à un stade ou ils permettent de compiler les composants d'Okawix sous Linux, Mac et Windows.

Sous Linux, la détection est faite grâce à pkg-config ; sous Mac et Windows aucune détection n'est tentée pour l'instant et l'utilisateur doit spécifier un chemin vers un SDK.

En plus de détecter les chemins des fichiers d'en-tête, des bibliothèques et des paramètres de compilation, le module XUL recherche l'emplacement des fichiers IDL, de l'exécutable xpidl et fournit même des macros pour faciliter la génération des fichiers .h et .xpt à partir des IDL.

Enfin, lorsque plusieurs SDK sont disponibles (ie les SDK "stable" et "unstable" proposés par pkg-config), le module permet de choisir un SDK suivant la disponibilité de certains composants. Par exemple, Okawix utilise nsIRunnable qui n'est pas dans le SDK "stable" ; il est alors possible de trouver le "bon" SDK en lui indiquant que l'on veut ce composant.

Le code est disponible sur un projet google et inclut un exemple de composant avec le CMakeLists.txt permettant de le compiler. Maintenant, je suis à la recherche de gens intéressés pour tester (voir utiliser) le truc et je suis preneur de tout retour : commentaire, suggestion, rapport de bug, etc.

Deux gros chantiers dans Gecko sont en cours : l'accélération matérielle graphique, et une nouvelle version majeur du moteur javascript.

Tout d'abord, l'accélération matérielle. La version windows de Gecko utilise maintenant, expérimentalement (dans les nightlies), Direct2D pour certaines opérations graphique. En fait ce support a été ajouté par Mozilla dans la bibliothèque graphique Cairo, utilisée par d'autres projets en plus de Gecko. Le support pour OpenGL 2.1 est prévu pour les autres plate-formes. Il y a déjà un support pour OpenGL, mais uniquement au niveau de l'API Canvas3D (WebGL), qui permet de faire de la 3D via l'élément Canvas (voir notre précédente news à ce sujet).

Ce support de l'accélération graphique servira à tout ce qui est "dessin 2D". Mais n'est pas suffisant. Le moteur de rendu dans Gecko est en train d'être ré-architecturé, en utilisant un système de layers. Chaque type de layer pourra avoir son propre type d'accélération graphique. C'est ainsi que les layers de type "video" pourront être accélérées en utilisant les spécificités des cartes graphiques pour les vidéos. Ainsi chaque partie d'une page web sera affichée d'une manière optimum. Pour en savoir plus, je vous recommande la lecture de cet article paru sur libre-ouvert, expliquant plus en détails ce système de layer.

Autre chantier, le moteur javascript. Jusqu'à la version 3.0 de Firefox, nous avions simplement le moteur SpiderMonkey, qui interprète à la volée le javascript, le transforme en bytecode et exécute ce bytecode. Dans la version 3.5, une évolution est apparu : le tracing. Le moteur JS (appelé TraceMonkey) repère les parties de codes répétitives, tout en tentant de détecter les types des valeurs utilisées. À partir de cela, il génère du code machine optimisé, ce qui évite de réinterpréter le javascript à chaque passe d'une boucle. Ce traitement est effectué précisément par Nanojit, un composant issue du projet Tamarin. Cependant, tout le code javascript ne peut être optimisé de la sorte, ce qui ne permet pas d'avoir des grandes améliorations de performances dans certain cas.

La prochaine évolution, pour le code qui ne peut être exécuté par le biais du tracing, va être de transformer celui-ci en code machine. C'est le projet JägerMonkey. Ils vont réutiliser pour cela Nitro Assembler, un "compilateur" issue de la version de webkit issue d'Apple. Celui-ci ne fait pas les mêmes types d'optimisations que NanoJit, mais le résultat sera le même : exécution direct de code machine. Il se pourrait bien que Mozilla rattrape, voir dépasse ses concurrents, en particulier le moteur V8.

Pour plus de détails, voir cet article en anglais du site hack.mozilla.org.

Mozilla a décidé de supprimer le support de XUL dans les pages web. Cela signifie que l'on ne pourra plus utiliser des éléments XUL dans application "distantes", hors chrome.

Cette décision a été prise à cause des trop nombreux problèmes de sécurités que XUL offre sur le web. Les développeurs de Mozilla veulent s'enlever une charge de travail et voudraient profiter de ce temps pour travailler plus sur HTML5 et XBL2. On ne sait pas encore si cette suppression interviendra dans la prochaine version de Firefox ou d'autres version futures. Vous pouvez suivre l'évolution via le bug 546857.

Bien entendu, cette suppression n'intervient que pour les pages web. Il n'est absolument pas question de supprimer XUL pour les extensions ou les applications XULRunner.

Cela va tout de même poser des problèmes pour tout ce qui est démonstration en ligne de XUL (en particulier celles qui sont hébergées sur xulfr.org). Et puis bien sûr, ceux qui auraient développé des applications web en XUL, celles-ci ne fonctionneront plus. Il y a toutefois des alternatives.

1. Il est tout à fait possible de réaliser une extension, comportant le minimum de fichiers, et ouvrant des pages XUL délivrées par un serveur web profitant des privilèges chrome. Par exemple, le nouveau CMS RBSChange utilise une telle technique. Certes, il faut installer une extension, mais l'essentiel de l'application se trouvant sur un serveur web, il n'y a pas besoin de mettre à jour l'extension à chaque évolution.
2. Vous pouvez continuer à profiter du modèle de boîte flexible de XUL, utiliser les propriétés -moz-box-* sur des éléments HTML (ainsi que display:-moz-box;). Ces propriétés CSS sont d'ailleurs spécifiés dans un brouillon du W3C, donc amenées dans le futur à devenir un standard, tout comme -moz-appearance. À noter que Webkit (donc Safari et Chrome) a une implémentation similaire de ces propriétés.

D'ailleurs, les éléments XUL seront conservés dans le DOM par Firefox lors du chargement du document. Rien ne vous empêche de vous faire donc une feuille de style xul.css pour rétablir les propriétés CSS pour XUL. Vous perdrez cependant les comportements et fonctionnalités par défaut des éléments XUL. Et il n'y a pas vraiment d'alternative. HTML5 prévoit bien quelques balises pour les menus et commandes (pas encore implémenté dans Firefox), mais rien pour un équivalent des templates, des trees etc...

Une nouvelle version de XulRunner est disponible. Elle contient Gecko 1.9.2, le moteur de Firefox 3.6, et contient donc toutes les nouveautés du navigateur, en particulier tout ce qui est lié à XUL et les extensions.

Vous pouvez télécharger XulRunner sur cette page et lire les notes de cette sortie.

Si comme moi vous utilisez un Mac avec une Magic Mouse, il y a de fortes chances pour que vous soyez confronté au même souci que moi. La Magic Mouse induit un défilement de page avec intertie, dans le sens où lorsqu’on la lache, le défilement s’adoucit peu à peu. Ça pose un souci si on [...]

Contenu initialement publié sur BeFox - www.befox.be

Mise à jour (14h15) : après quelques temps ça ne fonctionne de nouveau plus. Toujours aucune idée du pourquoi mais je pense que c’est en rapport avec le bug de Firefox 3.5, qui faisait que celui-ci n’avait pas le focus au lancement et terminait en arrière-plan. En fait pour être tout à fait honnête je n’ai [...]

Contenu initialement publié sur BeFox - www.befox.be

Firefox 3.6 est sorti en version finale il y a une dizaine de jour, ainsi que sa version mobile pour Maemo.

Le coeur de Firefox 3.6, gecko 1.9.2, apporte de nombreuses nouveautés au niveau des technologies web, et permettent, avec les autres avancées HTML5 présentes dans les versions précédentes de Firefox, de réaliser maintenant des applications web vraiment puissante.

Pour le montrer, Paul Rouget vient de sortir une nouvelle démo. Cependant, c'est plus qu'une démo, c'est une véritable petite application concrète.

Il s'agit d'un outil, qui permet d'envoyer des images sur twitpic et comportant un éditeur d'image. Vous sélectionnez les images que vous voulez envoyer, vous les retouchez éventuellement, et vous les envoyez. Visualisez la video, c'est carrément génial, d'un point de vue technique. C'est du jamais vu dans une application web HTML (si on met de coté les applet java ou flash, souvent lourdes et peu ergonomiques).

Coté technique donc, voici ce qui est utilisé :

• HTML5 Canvas: on ne présente plus l'élement <canvas>, qui permet d'avoir une zone dans la page web où l'on peut "dessiner" programmativement. Les images que l'on a glisser dans l'application sont "injectées" dans un canvas. Cela permet alors de les modifier, de proposer à l'utilisateur une mini application de retouche, avec des fonctions de découpage, de décoration, de mirroir etc. Avec Canvas, on peut aller très très loin. Voir par exemple cet outil, sketchpad, un paint-like bien plus beau que l'original :-)
• HTML5 Drag and Drop: Paul utilise les évènements drag-and-drop, pour permettre, d'une part, de glisser des fichiers de votre bureau ou explorateur de fichiers vers l'application, mais aussi de glisser les images à l'intérieur de l'application entre les différentes fonctionnalités (glisser une image précédemment sélectionnée vers la poubelle par exemple).
• File API : permet dans l'application d'avoir des informations sur les fichiers, à partir de ce qui est indiqué dans un <input type="file"> ou un évènement drag and drop qui concerne un fichier. Ça permet à l'application de réagir ensuite en fonction du type du fichier, de sa taille etc..
• HTML5 localStorage: localStorage est un objet javascript qui permet de stocker ce que l'on veut, durablement, coté client. Il est utilisé ici pour stocker les images sélectionnées, en attendant de les envoyer vers twitpic. L'image, affichée en fait via un canvas (ce qui permet de la modifier), est en fait transformée en data URL. Cette URL est alors stockée dans localeStorage.
• HTML5 Application Cache : toute la machinerie permettant de continuer à faire fonctionner l'application même en étant déconnecté, est utilisée. En particulier, un manifest "offline" est utilisé pour indiquer les fichiers de ressources (js, css) à stocker durablement dans le cache du navigateur, de manière à pouvoir recharger l'application, même en étant déconnecté. En fait, c'est comme si l'application était stockée en local. De plus, les évènements offline et online sont écoutés, pour pouvoir autoriser ou non la publication des images.
• Cross Site xmlHTTPRequest, un mécanisme http permettant d'autoriser ou non à une application web (ici la demo) de communiquer avec une autre application web (ici twitpic).

Toutes ces technologies, dorénavant présente dans Firefox 3.6 et déjà plus ou moins dans d'autres navigateurs (à vérifir, si ça ne l'est pas encore, ça ne devrait pas tarder), offrent de bien belles perspectives en matières d'applications web puissantes et agréables à utiliser, que ce soit pour les CMS ou pour les sites e-commerce.

Bien sûr, tout ceci est aussi utilisable dans une extension, facilitant alors leur développement.

Pour en savoir plus sur les nouvelles possibilités de Firefox 3.6/Gecko 1.9.2, n'hésitez pas à consulter la page Firefox 3.6 for developers.

On parle beaucoup de Firefox et pour cause, une nouvelle grosse mise à jour vient de sortir. Mais c’était oublier que Thunderbird a également vu son numéro de version être augmenté cette semaine. C’était la veille de la sortie de Firefox 3.6 et, pour être tout à fait complet, nous avons donc maintenant Thunderbird 3.0.1. Il [...]

Contenu initialement publié sur BeFox - www.befox.be

Comme annoncé cette semaine un peu partout autour du globe, Firefox 3.6 est aujourd’hui disponible. Cette version, appelée Namoroka, compte entre autres nouveautés le support intégré des Personas et des polices WOFF. Du côté du moteur de rendu, Gecko, c’est la version 1.9.2 qui est intégrée au navigateur. Ce ne sont pas les seules nouveautés de [...]

Contenu initialement publié sur BeFox - www.befox.be