Laurent J a écrit 2938 commentaires

le 4ieme chiffre est incrémenté quand il y a des bug fixes ou des petites améliorations, qui ne changent rien au niveau de l'API pour les extensions.

le 3ieme chiffre est incrémenté quand il y a des corrections de bugs ou des petites améliorations, qui peuvent rendre des extensions incompatibles, sans toutefois remettrent en cause toute l'api.

le 2ieme chiffre et 1er chiffre : incrémenté quand il y a des évolutions majeures, dans le moteur Gecko et/ou dans l'API, ce qui a de forte chance de rendrent les extensions incompatibles.

ah ?

display:table; c'est pourquoi faire à ton avis ?

et la propriété column ? (-moz-column)

Je veux dire que je n'ai pas l'impression qu'il y ait des manières simples de changer le style facilement. Bon, je me trompe peut être mais c'est l'impression que j'ai.

Et CSS ? C'est pas assez flexible ? ;-)

Dans la même serie d'editeur xml wysiwyg, il y a Etna, totalement opensource, basé sur Gecko. http://rhaptos.org/downloads/editing/etna/

Bon, pour l'instant, c'est pas vraiment encore utilisable "en production", surtout que la dernière version est pas mal buggée au niveau parser RelaxNG/validation, mais je vais sortir d'ici deux semaines (suis en congé là :-) ) une nouvelle version pour laquelle j'ai corrigé des tonnes de bugs.

Bien sûr, c'est du Gecko, donc multi-plateforme, système de themes/d'extension à la firefox (on peut ainsi ajouter des éléments d'interface propre à un type de document, pour docbook par ex) etc.

exactement, DocBook et latex n'ont absolument pas le même but. Docbook, ça sert à stocker, à structurer un contenu, pas du tout à presenter un contenu (ça, c'est le rôle de CSS).

Le but final de Latex, est plutôt de mettre en page. Je dirais que c'est un mélange stockage/presentation, à mi-chemin entre docbook et css (au niveau sémantique j'entend).

non c'est en partie la faute à cairo, sur lequel est basé l'implementation svg de gecko.

>Framework de qualité

mouhai... pour l'instant, c'est plus un PEAR 2 (une bibliothèque quoi) qu'un véritable framework.

Un framework, ce n'est pas juste quelques classes utiles, c'est aussi un environnement qui impose une organisation du code, une architecture, une organisation des fichiers. Un cadre quoi. (frame=cadre). Et ceci afin de s'y retrouver plus facilement.

le "framework" zend n'impose pour l'instant pas grand chose au niveau organisation du code. C'est plus une simple bibliothèque. Esperons que ça va évoluer vers ce qu'on appelle un framework. Comme symphony par exemple, ou mieux encore, comme copix ou jelix, qui proposent une architecture modulaire, un système évènementiel inter-module, une véritable organisation du code etc.. http://jelix.org

ça dit bien l'importance de trouver un standard pour unifier, sécuriser, étendre ajax et toute cette nouvelle façon de faire du web.

C'est ce qu'est en train de faire les groupes de travail webapi et webformat du w3c : normaliser xmlhttprequest, créer de nouveau format d'échange ( REX par exemple http://www.w3.org/TR/2006/WD-rex-20060202/ ), créer de nouvelles api pour faciliter le développement et profiter de nouvelles fonctionnalités etc.. (dialogue avec le presse papier, stockage local de donnée etc..)

Voir http://www.w3.org/2006/webapi/

Normalisation aussi de XUL, XBL2 etc en cours http://www.w3.org/2006/appformats/

Sinon, il ne faut pas oublier qu'il y a d'autres formats, standards, qui sont plus avantageux que ajax, tout en apportant au moins le même confort d'utilisation, beaucoup plus accessible, avec un temps de développement beaucoup moindre. Je pense en particulier à XForms langage déclaratif de formulaire qui évite de se taper des lignes de codes JS, de se taper du xmlhttprequest, pour faire de veritables formulaires. Par exemple, pour montrer à l'utilisateur que le contenu d'un champs est invalide : 0 lignes de code JS pour valider (un simple attribut à mettre pour indiquer le format attendu), et une pseudo-class CSS3 à mettre pour le signaler :

#monchamps:invalid { background-color:red; }

XForms permet aussi par exemple de charger de nouvelles données dans le formulaire, sans recharger la page (chose que l'on doit faire à grand renfort d'ajax dans les formulaires html traditionnels)...

Ajax c'est bien, mais c'est bien souvent l'usine à gaz pour pas mal de chose : il faut voir aussi ce qui existe à coté.

(PS: y a pas d'inconvénient à utiliser XForms : des plugins existent pour IE, une extension existe pour FF etc. http://www.mozilla.org/projects/xforms/ )

>C'est pourtant un mot assez utilisé,

Dans ton patois peut être. En français non. (pourtant, je suis informaticien hein).

Qu'on emploi des mots anglais quand il n'y a pas véritablement de traduction, passe encore. Mais qu'on le décline en plus à la française ("scalabilité", ce qui ne veut absolument rien dire), non, faut pas pousser.

>Je n'ai malheureusement pas vu vos félicitations sur d'autres dépêches à croire que le franglais est partout de nos jours.

Désolé, j'ai pas le temps de féliciter tous les auteurs des dépeches qui redigent dans un français à peu pres correct. Y en a beaucoup trop.

D'ailleurs, ce serait plutôt

"L'adaptabilité aux montées en charge a été améliorée grâce à la possibilité de faire des sauvegardes compressées"

On comprendrait mieux...

Non mais franchement, quelle horreur ce franglais ! scalabilité !! C'est abusé là !

C'est si dur que ça que de dire "adaptabilité", "extensibilité" ou des termes de ce genre ??

une augmentation de la scalability (gestion de la montée en charge)

"une amélioration de la gestion de montée en charge"

(tout simplement)

La scalabilité a été améliorée en permettant la sauvegarde de façon compressée

"L'adaptabilité aux montées en charges a été améliorée ..."



Bientôt, on va avoir des news en sms... Je ne félicite pas l'auteur, ni les modérateurs d'ailleurs..

À noter que parmis les nombreux langages objet à prototype, il y a Javascript.

Sinon pour plus de détails, je vous recommande la lecture de l'article sur wikipedia http://en.wikipedia.org/wiki/Prototype-based_programming (la version française est plutôt maigre..)

comment ça pub ehontée ?


C'est une alpha1. C'est pas une finale. Et beaucoup de chose vont encore changer d'ici là.

> Tiens au fait, qu'utilises les gentils pour télécharger efficacement de gros fichiers ?

FTP. (voir HTTP pour certains sites).

par contre, je ne suis pas sûr qu'il faille passer par l'option de configuration indiquée pour indiquer des fichiers distants. Faut peut-être modifier le gestionnaire de bookmarks pour ça...

FTP non : tout le protocole n'est pas implémenté.

Pour HTTP : suffit d'indiquer la méthode (PUT, DELETE, GET, POST ....) coté Firefox (avec xmlhttprequest par ex). Le problème est plutôt du coté du serveur web. il faut :

- soit que le serveur web (apache &co) prenne en charge la totalité de la spec HTTP, pour qu'il modifie/supprime/créer de lui même le fichier cible (et qu'il y ait je suppose les droits bien configurés)
- Soit un script (PHP ou autre) qui fasse la manip en fonction de la méthode indiquée.

Mais le tiroir sera ouvert seulement en aout, et il libérera Firefox 2 qui proposera un tout nouveau système de stockage de liens. Nom de code de ce système : Places http://wiki.mozilla.org/Places .

Il utilisera comme moteur de stockage SQLLite. (aka mozStorage).

Vous pouvez d'ailleurs commencer à le tester (sauvegardez votre profil !). "Bon Echo" (Firefox 2.0 alpha 1) est sorti aujourd'hui. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/bonec(...)

Oui mais XUL n'y est pour rien. (XUL c'est juste pour l'interface).

Cependant, XUL c'est rapide quand même :-)

> ou que le XML est imposé car "a la mode"

Elle dure la mode, vu le nombre d'année qu'existe XML... :-p

XML, ce n'est pas une histoire de mode. Si on l'utilise de plus en plus, c'est parce que (à mon avis) la puissance des machines d'aujourd'hui permet de profiter toute la puissance d'XML, de toutes ses possibilités, et que par la même occasion, on dispose de plus en plus d'outils et de bibliothèques.

Et puis des specifications de technos annexes à XML (xsl, xpath, xquery, rdf, etc...) sortent, s'améliorent. Bref, ça devient vraiment interressant d'utiliser XML. ça devient universel.

Bon, ok, XML c'est verbeux, et ça coute plus en bande passante.

Le choix de XML est tout de même judicieux : cela améliore l'interoperabilité.

Quand tu n'as pas de spec et que tu as un flux xml, le reverse engeenering est plus facile sur ce genre de type de donnée même si le nom des balises n'évoque pas grand chose, que sur un flux binaire contenant une suite d'octet pas trés logique, L'information est structurée.

Ensuite, cela permet d'éviter d'écrire un énième parser de flux. Parser XML + api DOM pour en extraire les données et basta. Pas de nième bibliothèque bas niveau à développer, ou dont il faut apprendre l'API.

Ensuite cela permet des choses sympa. Genre pour des passerelles entre deux flux de formats xml différents. Une feuille XSLT pour transformer un message d'un format A à un format B et basta (bon, ok c'est super théorique et simpliste comme exemple, dans la réalité, ça peut être plus compliqué, tout dépend des différences entre le format A et B).

Alors c'est sûr, XML est plus gourmand en ressource.

ok, ça *semble* pauser un problème pour les crédits & cie.

Mais le problème, c'est que tu confrontes des difficultés dans le contexte présent (système de CDI/CDD ..) avec un contexte qui va évoluer (CDI/CDD/CPE etc..)

Le fait qu'il y ait ce CPE, cela ne va-t-il pas changer la donne dans les banques par exemple ? plus de CPE, moins de CDI, ça voudrait dire, qu'avec leurs exigeances actuelles, elles auront moins de clients. Ne vont-elles pas finir par être plus souples ?

Idem pour les propriétaires ou les vendeurs immobiliers ou je ne sais quoi d'autres.

Ce que je veux dire, c'est que beaucoup basent leur argumentation avec un contexte donné, le contexte actuel. Or celui-ci, avec le CPE, va modifier, forcément. Aussi cela ne veut pas dire que les choses ne vont pas évoluer ailleurs, pour s'adapter à ce nouveau contexte.

Qui peut prédire qu'on ne pourra pas emprunter avec un CPE ?

>creer des castes entre ceux qui ont leur CDI et ceux qui ne l'ont pas.

ça tu l'as déjà avec le CDD si on suit ta pensée.

>Sans compter que le jour ou tu perds ton boulot, tu perds ton assurance maladie avec!

Ce n'est pas le cas justement en France il me semble.

D'aprés les anti-cpe oui. Parce que tu comprend, les patrons ils ont que ça à faire, de virer les gens.

D'ailleurs, aux états unis, où tu peux être virer à n'importe quel moment et où tu dois faire tes cartons dans l'heure qui suit ton licenciement (et pas seulement pendant 2 ans, mais tout le temps), il a été prouvé que ce système ne fonctionne pas depuis des dizaines d'années (euh, en fait depuis le début des états unis). La preuve, ils sont devenu une grande puissance mondiale.

Sinon bon, j'admet que c'est emmerdant d'être pendant 2 ans au lieu de 3 mois en période d'essai, et licenciable à tout moment pendant cette période.

M'enfin quand tu es un bon élément, il n'y a pas de raison pour qu'un employeur te vire au moindre pretexte. Ou alors il est con. Et dans ce cas, ce n'est pas si mal de changer d'employeur.

Ou en fait, c'est peut être ça qui pose problème aux jeunes : ça va les forcer à bien bosser.

Meeerrrdeeuuuu !!!

>Wengo n'est pas vraiment compatible SIP et c'est même volontaire.

Wengo repose sur des bilbilothèques SIP libre.

D'où tiens-tu ces (dés-)informations ?

je vois pas le rapport avec le problème évoqué. L'interface d'epiphany est native gtk2. Sur firefox, y a une couche en plus, XUL + CSS, d'où la différence de perf entre epiphany et firefox.

Mais là on parle de perf entre une appli sous windows et une appli gtk2 tounant sous X, et plus exactement en ce qui concerne Firefox.

La différence entre la version Windows et la version Linux/gtk2 pour Firefox, ça concerne quelques centaines de lignes de code. Voir http://lxr.mozilla.org/mozilla1.8/source/widget/src/ et http://lxr.mozilla.org/mozilla1.8/source/gfx/src/

bref, la version Windows et Gtk2 de Firefox ont en commun des millions de lignes de codes, et seulement un tout petit pourcentage de difference qui est en gros l'api d'appel au toolkit (toolkit windows, ou toolkit gtk2)

On ne peut vraiment pas dire qu'il y a de la part des développeurs de Mozilla une volonté d'optimiser plus la version windows que gtk : c'est faux vu le peu de ligne de code que ça concerne au final dans Firefox. Étant donné qu'en plus, ce qui pompe le plus de ressources au niveau temps processeur, voir peut etre mémoire, c'est la partie content/Layout, la partie qui calcule tous les élements à afficher à partir d'un contenu XUL, xml ou html, en tenant compte des CSS. Et dans cette partie du code, y a trés peu de différence entre la version windows et la version gtk2.

bref, à mon avis, ce qui fait donc la différence, c'est bien le toolkit utilisé. De toute façon on le voit bien : les manipulations de fenêtres sont plus réactives sous windows que sous kde ou gnome. Quand on passe de l'un à l'autre, c'est flagrant. (on s'en rend d'autant plus compte quand la machine n'est pas dernier cri ou la carte graphique de puissance trés moyenne).

j'ai basé mon estimation sur http://www.kernel.org/pub/linux/kernel/CREDITS où il y a prés de 200 noms répertorié. Il est bien indiqué que c'est une liste partielle.

Je me suis dis alors, il doit en manquer peut etre quelques dizaines (à cause de peut etre quelques difficultés à obtenir des infos sur ces quelques contributeurs...). Par contre si il y en a vraiment 5000, pourquoi ne mettre que ces deux cents noms ? En quel honneur ces 200 noms et pas les 5000 ?