utiliser des triggers, c'est pas moins performant que de faire soit même les requêtes à partir du programme. Il faut bien évidement faire attention aux cascades que cela peut entrainer.
Mais utiliser un trigger pour mettre à jour une table après la modification d'une autre table, je ne vois pas en quoi c'est moins performant que de faire les deux requetes à la suite en php par exemple.
bon sinon, comme ton commentaire précédent, je n'ai pas tout compris, il manque des mots dans ta phrase. "et niveau maintenant " : tu voulais dire quoi ?
non, parce que ça veut dire que pour inserer les elements il faille explicitement appeler cette procédure stockée. Et ça veut donc dire que si, pour une raison ou une autre, à un moment il soit fait directement un insert dans la table, la procédure n'est pas appelée. Du coup, cohérence des données cassée.
L'intérêt des triggers c'est que ça permet une implémentation beaucoup plus transparente de tes règles de gestion. Un développeur n'a pas à connaitre des dizaines de procédures stockées, et savoir quand il doit appeler une procédure ou quand il peut faire une requête directe sur la table. Avec un triigger, il fait son insert sans se soucier de rien du tout, et tout se fait automatiquement.
Et on peut mettre aussi les applications au même plan que le développeur. Imagine plusieurs applications qui attaquent la même base (ça arrive très souvent dans les moyennes et grosses boites). Imaginons donc que l'on ait, en reprenant mon exemple, à ajouter un champs qui est calculé à l'insertion ou modification d'un enregistrement. Si je fais ça dans une procédure stockée, je vais devoir modifier aussi toutes les applis pour qu'elles appellent la procédure stockée plutôt que de faire leur insert. Avec un trigger, pas besoin, ça sera transparent pour elles.
Note qu'un trigger peut appeler une procédure stockée. Et qu'une procédure stockée reste toutefois utile pour les problèmes plus complexe que de simple opération à exécuter sur des changements sur une table ou autre.
On peut aussi optimiser en rassemblant les requêtes. Si par exemple on doit faire 3 insert à la suite sur la même table, rassembler tout ça en un seul insert.
On peut aussi faire de la duplication d'informations (mais pas trop :-)). Par exemple, on affiche une liste de discussions, et on veut afficher pour chacune d'elles le nombre de reponses. Plutôt que de faire un count pour chaque discussion et/ou des group by , on pourrait mettre un champs qui contient le nombre de réponse, ça évite d'avoir à le "calculer" à chaque fois, ça évite les jointures. Certes, ça fait pas très propre pour un puriste, mais d'un point de vue pragmatique, ça permet d'améliorer les perfs.
Et puis en mysql 5, on peut aussi utiliser les triggers. Alors si on doit effectuer des modifications sur d'autres tables quand on en modifie une, utiliser les triggers. ça évite de faire X requetes "à la main", et sera bien plus optimisé au niveau execution (et puis le code client sera plus propre). les triggers ça permet aussi de garder une cohérence dans le schema sans avoir toutes les rêgles de gestion en tête. Par exemple, lors de l'insertion d'une réponse dans la base, le trigger ira faire un update du champs "nombre de reponse" sur la discussion ;-).
Ouai, je viens de regarder ça aussi. C'est en fait juste un moteur de template dédié à ODT, avec deux trois fonctions pour faciliter l'injection de texte et d'image, et qui sait ouvrir/enregistrer un zip...
Dommage, ils auraient pu developper des plugins pour un moteur de template existant (au hasard, jtpl ou smarty), cela leur aurait fait un peu moins de boulot, tout en profitant des fonctionnalités de ces moteurs (parce que bon, leur langage de templating est plutôt super limité, pas de gestion de cache etc...).
>Des solutions WYSIWYG plus simples de prime abord existaient, mais elles étaient - pour le moment - toutes propriétaires.
Non, pas toutes, il y avait le projet Etna, que j'ai commencé à développer il y a presque 5 ans. Entièrement libre, basé sur Mozilla (qui possède un bon moteur de rendu, et des fonctions d'éditions mais que j'ai du quand même hacker). http://etna.disruptive-innovations.com
Malheureusement, faute de temps, il n'est pas encore prêt pour une utilisation en production, et je peine à trouver du temps (surtout depuis que je ne suis plus chez disruptive innovations) pour finaliser une nouvelle version qui contient un nouveau validateur RelaxNG temps réèl plus costaud, et basé sur un gecko plus récent...
Sinon, pour répondre à certaines questions, faire du XML wysiwyg (ou plutôt de l'édition "visuel" d'un document XML, sans que l'utilisateur ait à écrire/à voir du XML), c'est plutôt compliqué, voir plus compliqué que de faire un éditeur HTML wysiwyg.
Quand l'éditeur connait en natif le format XML, (genre Kompozer pour (x)html, ou OpenOffice pour odf), on peut "cabler" en dur des comportements pour tel ou tel balise, voir même à la limite transformer le document XML en un truc binaire qui serait plus facilement exploitable par le moteur de rendu et d'édition.
Mais quand il s'agit d'un éditeur générique, c'est à dire qu'il puisse éditer visuellement n'importe quel type de document XML, ça se complique. Il faut d'abord fournir à l'éditeur un schéma pour qu'il puisse faire de la validation, qu'il sache quel element on peut créer et où, et vérifier le contenu textuel que l'on insère dans ces éléments... Mais ce n'est pas suffisant, car l'éditeur doit pouvoir savoir comment afficher ces balises, si par exemple ce sont des balises qui représente des blocks, ou si ce sont des élements "inlines" (comme le strong en XHTML par exemple.) Malheureusement, il n'est pas possible de fournir ce genre d'informations dans les formats de schemas existants (XMLSchema ou RelaxNG, et puis DTD, on oublie hein).
Il n'est pas possible non plus d'indiquer quel est le contenu par défaut quand on crée tel élément. L'éditeur peut éventuellement le deviner à partir du schema, mais quand il y a plusieurs choix possibles, ben il prend le premier, qui n'est pas forcément celui que veut l'utilisateur...
Manque aussi tout ce qui est descriptif. Un éditeur XML générique, il ne sait pas ce qu'est la balise P en XHTML. Et indiquer "inserer un P" à l'utilisateur, ça va pas beaucoup aider ce dernier. Il faut donc un moyen de dire à l'éditeur que P, c'est un "paragraphe", afin que l'interface soit intuitive. Il faut aussi apporter des descriptions pour que l'utilisateur puisse faire son choix quand, lorsque pour créer un élément, il y a plusieurs choix autorisés par le schema.
Bref, il n'y a rien de prévu dans XMLSchema et RelaxNG pour les éditeurs. Il faut donc fournir ces informations, en plus du schema.
Dans Etna, ça passe par des balises supplémentaire dans RelaxNG (c'est autorisé par la spec RelaxNG) pour tout ce qui est nécessaire à l'édition proprement dite. Et pour ce qui est de l'affichage, il faut fournir une feuille CSS.
Il y a aussi des problèmes d'interfaces utilisateurs. Même dans un document XML orienté textuel, il y a des éléments contenant des informations "techniques" (des metas datas, ou le titre du document par exemple). Là encore, l'éditeur wysiwyg ne peut pas deviner la nature de ces éléments. Et il est préférable que ces informations soient édités avec une interface dédiés. Il faut donc que l'éditeur fournisse des "hooks" pour pouvoir lancer par exemple une boite de dialogues pour éditer ces choses (genre dans open office, la boite de propriété du document). Bref, il faut fournir des éléments d'interface graphique à l'éditeur. Dans Etna, ça passe donc par la réalisation d'une extension (à la firefox) (et la feuille de styles CSS cache les éléments qu'il faut pas éditer via la zone d'édition) .
Enfin, pour les questions à propos de l'utilité d'un editeur XML "wysiwyg", posez vous alors la question : préféreriez vous éditer un document open-office "à la main" avec VI ? Pensez vous que cette méthode d'édition serait plus pratique pour madame michu pour écrire son courrier ? Pour ma part, je dis non. L'utilisateur en à la limite rien à foutre du format. Ce qu'il veut, c'est écrire son document le plus simplement du monde, et que ce document puisse être ensuite utilisé correctement par d'autres outils éventuels (l'éditeur doit produire du XML valide etc.)
Mais maintenant, un éditeur XML wysiywg n'est pas fait non plus pour éditer n'importe quel type de fichier XML. Ca reste bien entendu utile que pour les formats XML orienté documents textuels (docbook, xhtml, odf et j'en passe). Ça n'a bien entendu aucun sens d'éditer par exemple un fichier de configuration XML avec ce genre d'outils. Pour ce genre de document, c'est plus une interface utilisateur graphique qu'il faut, pas une surface de rendu/d'édition textuelle.
Enfin il faut savoir qu'il y a pas mal de domaines et d'industries, où des documents textuels sont stockés en XML, et dans un format XML qui leur ait propre parce que mieux adapté à leurs besoins et parce que leur système d'information a été conçu avec ce format.
J'ai l'exemple d'ailleurs de Rice University (qui commanda le projet Etna), qui stockent leurs cours dans leur propre format XML, et qu'ils publient ensuite sur le web (après transformation via XSLT). Et les gens qui éditent ce genre de document avaient voulu une sorte de traitement de texte, plutôt que d'apprendre le markup du format, ou d'utiliser ces éditeurs XML arborescents et peu pratique finalement pour ce genre de documents... (et malheureusement, suite à l'ouragan catherina, leur budget a été restreint, et n'ont pas pu continuer à financer le projet Etna...)
Enfin pour conclure, les éditeurs XML wyiwyg, c'est comme pour les browsers ou les éditeurs HTML wysiwyg : y en a très peu en open source, parce que ça demande des compétences spécifiques, ça demande de la recherche (donc du temps, donc des sous) parce que c'est un domaine complexe (tant au niveau technique qu'au niveau interface utilisateur), et qu'il y a peu d'expériences "publiques", de feedback, pour aider à leur réalisation.
Ben utilise Thunderbird alors. Comme firefox, tu peux configurer certaines couleurs, et même fournir une feuille de style personnalisée à stocker dans ton profil, qui surchargera les styles CSS du mail, en utilisant bien sûr la simple cascade CSS.
Tu ne penses pas aux utilisateurs malheureusement. Si chaque fonctionnalité est 'à coté', ça veut dire que personne n'aura la même installation, les mêmes fonctionnalités dans leur navigateur. ça veut donc dire qu'aucun site ne fonctionnera correctement chez la majorité des utilisateurs. Bref, ce sera encore plus la merde qu'actuellement avec les différences qu'on a entre les differents navigateurs du marché. Si en plus pour chaque "marque" de navigateur, on a des possibilités différentes, ça va être l'horreur pour les développeurs.
De plus, mettre des choses "à coté", ça existe déjà, ça s'appelle des plugins, (ou des extensions pour les fonctionnalités utilisateurs). Et on voit bien ce que ça donne : c'est la grosse merde. (un seul est arrivé à s'imposer, flash).
Or, l'intégration des plugins dans une page est très limité. On est quand même vachement bridés sur ce qu'on peut en faire (du point de vue du développeur web).
Et il y a qu'à voir tout ce qu'on peut faire maintenant avec la balise video, qu'on ne pouvait absolument pas faire avec un plugin de lecture video classique, quel qu'il soit. cf les demos ici : http://people.mozilla.com/~prouget/demos/
Et pourquoi c'est possible avec la balise video ? parce que le moteur de rendu a le contrôle entier sur l'affichage, il peut modifier l'affichage de la video (à partir par exemple des filtres svg qu'on lui donne, ou des styles css et cie)... Ce qu'il ne peut absolument pas faire via les plugins, puisque ce sont les plugins qui décident ce qui doit être affichés.
Bref, l'intégration des technologies dans un même environnement permet beaucoup, beaucoup plus de choses que d'assembler des trucs divers qui fonctionnent chacun dans leur coin.
Maintenant, je vois pas non plus pourquoi on ne pourrait pas avoir des applications web quasi aussi fonctionnelle que celles que l'on a sur le desktop, sous prétexte que ça allourdi les navigateurs.
Mais tu manques de cohérence dans ton discours. Tu es contre ce progrés. Mais alors je me demande pourquoi tu n'es pas resté avec Netscape 4 sur ta machine hein.
Pour finir, tu trouves que le navigateur devient un bloatware : ça tombe bien, on a jamais assez de contributeurs. On t'attend sur les newsgroup de Mozilla pour en discuter et pour que tu nous proposes des solutions (qui soient réalisables bien entendu). Et je ne te dis pas ça méchamment ou autre : je suis sérieux. Viens donc proposer tes solutions techniques (avec un minimum de crédibilité, c'est à dire en sachant comment fonctionne un moteur de rendu web en gros).
pas du tout (ça fait quand même 6 ans que je bosses avec/sur Mozilla). Firefox, ce n'est que quelques fichiers XUL et js au dessus de XulRunner, lui-même au dessus de Gecko. Ce n'est pas Firefox qui gère les processus ou autre, c'est Gecko. Gecko est plus qu'un moteur de rendu, c'est tout un ensemble : moteur de rendu + couche reseau + couche d'abstraction du système + gestion des processus etc... Bref, tout ce qui est systeme/technique/rendu. Tu lui adjoint ensuite un toolkit XUL, et des composants utilitaires (fichiers, système de mise à jour etc), ça te donne XULRunner. À ça tu y ajoutes des composants spécifiques à ton appli, des fichiers XUL/JS et autre, ça te fait une appli : Firefox.
Actuellement, Gecko ne permet pas de charger un fichier HTML/XUL dans un processus différent. Ce n'est pas en modifiant quelques fichiers XUL et composants de Firefox qui vont permettre de le faire
>tu dis qu'il est impossible de réécrire les millions de ligne mais que les developpeurs sont en train de faire le multi-process, ce qui est bien la preuve que c'est possible d'avoir une architecture correcte sans tout réécrire
Si l''architecture de Gecko aujourd'hui, permet de developper le multi-process sans avoir à tout réécrire, c'est parce que Gecko évolue sans cesse. L'idée du multi process dans Gecko n'est pas nouvelle, ça fait plusieurs années que les core-developpers y pensent (cf sur les newsgroup de Mozilla). Aujourd'hui, il reste encore beaucoup de boulot, et ils sont quand même une petite équipe à temps complets pour y travailler. ça va représenter des patchs énormes quand même. Quand je dis, "sans tout réécrire", il faut relativiser en ayant en tête les millions de lignes de codes Mozilla...
>c'est que quand Chrome est sortie cela a mis en lumière que l'architecture de FF était pourrie..
non, raté. ça juste mis en lumière l'idée qu'il est intéressant d'exploiter aujourd'hui le multi processing dans les browser, grâce à la généralisation des processeurs multicoeurs, mais aussi de l'usage que l'on fait aujourd'hui d'un navigateur.
>Tu sais que sur le coup, je savais pas si t'étais sérieux ou si ton commentaire c'était une blague sur la bloatitude de Firefox!
ce dont je suis sûr en tout cas, c'est que tu es de super mauvaise foi
>Je sais pas pour vous, mais moi j'ai un "vieux" monocore à la maison.
et alors ? un vieux monocore sait lancer plusieurs processus non ? à moins que tu ais DOS comme OS... ou un 286 comme proc..
Jusqu'à maintenant, Gecko n'utilise que des threads, ce qui n'est pas suffisant, et ne permet pas d'isoler chaque page. L'utilisation des processus permet de le faire, et donc si une page "plante" (à cause, par exemple de flash qui part en sucette), ça n'impactera pas sur le navigateur.
>API OpenGL: c'est pour avoir une vraie partie de Unreal Tournament en arrière-plan de la page pendant que tu lis le blog des joueurs!
Il y a des sites qui ont besoin d'afficher des choses en 3D, et pas forcément des jeux (je sais pas moi, genre un site educatif qui montre un truc en 3D).
Bref, fait une recherche sur le web, tu as plein de truc pour faire du 3D dans une page web. Malheureusement, c'est du pur JS, c'est lent, et ça n'utilise pas l'accélération de ta carte graphique.
une API 3D, c'est une VRAIE demande de pas mal de développeurs web.
Et ça permettra, entre autre, aux développeurs de jeux de se passer de flash...
>J'imagine le futur de demain:
Ben non, tu l'imagines mal. Bien au contraire, et parce que Firefox pourra mieux utiliser les capacités de ta machine, que ce soit au niveau de l'utilisation des processus ou de l'accélération matériel de ta carte graphique, il n'y aura pas besoin d'avoir une machine plus puissante pour faire la même chose qu'aujourd'hui en mieux et plus rapide.
à noter que Firefox renseigne sur la localisation seulement si l'utilisateur l'a approuvé : une demande de confirmation s'affiche dés qu'un site veut acceder aux fonctions js qui donne la localisation.
Et donc tu te proposes pour réécrire les millions de ligne de code de Gecko ?
L'architecture de Gecko n'est pas toute pourrie. Elle est très bien et elle évolue depuis 10 ans, même si elle a ses défauts (comme toute architecture).
Sans dénigrer nullement le formidable travail de l'équipe de Chrome, c'est "facile" (entre guillemet, parce que faire un navigateur, c'est tout sauf facile) pour eux d'avoir une architecture différente et adaptée au matériel d'aujourd'hui : ils n'ont pas eu à gérer un passif de 10 ans, ils n'avaient pas de développeurs occupés à maintenir des versions précédentes. Ils avaient toutes leurs ressources focalisées sur le développement de leur navigateur. (sans compter qu'ils avaient déjà une bonne partie du boulot de fait : le moteur de rendu Webkit).
Et pour créer leur navigateur, ils pouvaient se dire : "alors voilà, aujourd'hui les contraintes matériels et OS, c'est ceci cela, la concurrence ils proposent ça et ça mais pas ça. On pourrait donc proposer ceci-cela à nos futurs utilisateurs. Mettons nous au travail."
Faire le même raisonnement en essayant de se projeter 10 ans en avant : c'est tout bonnement impossible (10 ans, c'est une éternité dans le monde informatique). Et dans 10 ans, l'équipe de Chrome aura le même problème que Mozilla : faire évoluer l'architecture de leur produit en tenant compte des évolutions matériels/logiciels/utilisations, mais aussi de la base utilisateur actuelle, c'est à dire pas tout casser d'un coup (les extensions par exemple). Sans perdre non plus des contributeurs qui n'arriveraient peut être pas tous à suivre un changement radical dans le code (que ce soit en temps d'adaptation de compétence sur le code, que d'acceptation de ce changement etc)
Bref, changer d'architecture, ça se fait pas en un claquement de doigt. Et une architecture, ça n'est pas forcément "pourri". Ca dépend du contexte, de l'objectif et de bien d'autres choses.
Et je trouve que les core-developpeurs de Gecko s'en sortent plutôt pas mal jusqu'à maintenant.
Sinon pour ton information, le multi-processus dans Gecko est dans le pipe [1], ça commence même à fonctionner. [2]
Et à priori, ça pourra se développer sans tout casser (ils pensent même trouver un moyen qui éviterait de trop casser les extensions agissant sur les pages web). Comme quoi, l'architecture de Gecko, elle n'est pas si pourrie que ça.
- implémentation de XBL2 (spec W3C qui attend deux implémentations avant de passer en recommandation) et qui fera exploser le web :-)
- le support multiprocesseur (un processus par tab etc...)
- API 3D sur la balise canvas (API reposant sur openGL, et en cours de spécifications avec Khronos Group)
- les animations SVG (déjà en partie dans le trunk)
- toujours plus de propriétés CSS
Il y a des centaines de tests en tout genre, des monitors internes à gecko pour connaitres les leaks, la consommation en mémoire etc. Et ceci est testé sur plusieurs machines differentes (ce qu'on appelle les tinderbox), sur des os differents, et en permance. Voir par exemple la page http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox qui montre les résultats de compils, de tests de performance etc... (cliquer sur les petits liens "ts", "tp" et cie, qui montrent les resultats..). L'ensemble de ces résultats sont visibles sur http://graphs-new.mozilla.org/
Pour tester les extensions, les developpeurs ont entre autre une extension, leakMonitor, pour savoir qu'est ce qui leak dans leur code.
Note que tout ces outils ne datent pas d'hier, et sont utilisés/améliorés depuis pas mal d'année.
le safe_mode est un cauchemar pour les développeurs PHP, surtout dés que tu manipule des fichiers dynamiquement. genre, tu arrive à creer un fichier, et la requete d'après, tu ne peux plus y toucher, à cause de ces droits mal foutus.
Et puis ça apporte plein d'autres problèmes que je n'ai plus en tête, à tels point que de l'aveu même des core-developer de PHP, safe_mode c'est du vent, c'est de la fausse sécurité et ça sera supprimé dans PHP6.
ce n'est pas la CSS, mais le parser de linuxfr, qui vire les blockquote. Cette balise n'est plus supportée pour de mauvaises raisons. https://linuxfr.org/tracker/776.html
Et il ne faut pas croire que Mozilla ne fait que se réveiller maintenant. C'est un projet qui a demarré il y a quelque temps déjà, et c'est le résultat de plusieurs réflexions qui ont eu lieu ces dernières années, voir les discussions sur les newsgroups (bah ouai, ce genre de concepts, ça date pas d'hier). Parce que bien évidement, ce genre de chose nécessite de ré architecturer certaines choses dans Gecko, qui ne sont pas anodines du tout. Et cela nécessite donc aussi du temps et des ressources. D'où le retard sur ce domaine là par rapport aux autres.
>Combien tu veux parier que les 3/4 des fontes TTF qu'on va trouver avec FF3.5 seront distribuees en violation de la license d'utilisation?
En cherchant un minimum, il y a quand même plusieurs sites proposant des fontes TTF gratuites.
> Le but de Firefox et de Mozilla, c'est d'avoir une base d'utilisateurs importante, sinon toutes les tunes de la vente de la barre de recherche a Google, elles disparaissent. Donc au moment de choisir les fonctionnalites a implementer, une grosse partie de la decision prend ca en compte. Entre refaire l'UI pour une meilleure ergo ou implementer SVG ou SMIL, le choix est vite fait.
bon, alors, une petite info, parce qu'à priori, tu n'es pas au courant (mais chuuut)
1) il semble que Mozilla ait assez d'argent maintenant pour s'auto-financer (les intérêts gagnés sur les sous mis de coté suffisent à faire vivre la boite)
2) Quand on regarde l'interface de Firefox 3.5, on remarquera quand même qu'il n'y aura pas de grand révolution pour l'utilisateur, entre la 3.0 et la 3.5. La plupart des développements ce sont fait principalement sur Gecko, avec l'implémentation de nombreuses features issues de standards. cf https://developer.mozilla.org/en/Firefox_3.5_for_developers , que tu devrais lire.
Car tu verras que SMIL et SVG, ce n'est pas si plus important que tout ce qui a été fait. Et tout ça en parallèle au développement de SMIL, puisque finalement quelque jours après la création de la branche pour Firefox 3.5, le patch pour SMIL était balancé dans le trunk (mais pas assez terminé, testé et cie pour être dans la branche FF3.5)
mmm... certes je crache sur IE, mais il me semble que dans mon commentaire je crache plus sur la campagne que sur le navigateur...
Maintenant, il me semble qu'en terme de support des standards et autres technologies, ils restent encore loin derrière gecko, webkit et opera. Super, il supportent CSS2.1 complètement par rapport à d'autres (Gecko...), mais bon, ils ne font que rattraper leur retard, et ils en ont encore à rattraper.
>Le coup des fontes telechargeables, paye toi ta mauvaise foi. Il y a pas si longtemps, y avait rien du tout dans Mozilla, forcement tu pouvais moins la ramener.
Mauvaise foi à demi quand même. Ils ne supportent pas ttf, mais juste un format qu'ils ont créé, non standardisé (bon, c'est vrai, en même temps, le W3C n'en a pas voulu).
Bon mais on va pas faire la bataille de celui qui implémente le plus de chose en CSS, à ce jeu là, Webkit ou même Gecko gagnent à coup sûr.
>Quand Firefox va se faire coiffer au poteau sur l'implementation du prochain test acid, tu vas venir nous expliquer que bon, y a des trucs plus prioritaires, hein. Et puis le support des standards, ca passe apres la base d'utilisateurs...
Qu'il y ait des trucs plus prioritaires que passer le test acid, en effet, c'est le cas. Par contre, il ne me semble pas avoir dit que les standards passent après la base d'utilisateurs (en tout cas je n'ai pas compris ce que tu voulais vraiment dire par là).
Il y a des standards, c'est un enjeux, c'est l'objectif de Mozilla, et cela l'a toujours été. Mais il y a des standards plus prioritaires que d'autres. FF3.5 ne passe pas le test acid3 complètement. Mais les points qui ne passent pas encore concernent principalement les animations SVG, qui sont déjà implémenté en partie dans la version trunk de Firefox. Les animations SVG, c'est bien, mais le support de la balise video, ou des trucs comme le offline, JSON, le drag and drop, la geolocalisation etc (1) sont un poil plus important, surtout dans cette époque où les internautes deviennent de plus en plus itinérant, utilisent de plus en plus la video etc. Et malheureusement, Acid3 ne teste pas ces trucs là... Comme quoi, les tests Acids ne démontrent pas tout...
Alors bon, si un jour IE dépasse Firefox en terme de tests Acid, tant mieux pour eux. Mais ils ont encore plus de boulot que Mozilla...
Ah oui, j'ai oublié de faire remarqué. Le nom de domaine du site est censé être http://www.tengrandisburiedhere.com (voir le code source de la page et les images), mais ce nom ne mêne nulle part.
[^] # Re: Problème de clés ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance MYSQL. Évalué à 3.
Mais utiliser un trigger pour mettre à jour une table après la modification d'une autre table, je ne vois pas en quoi c'est moins performant que de faire les deux requetes à la suite en php par exemple.
bon sinon, comme ton commentaire précédent, je n'ai pas tout compris, il manque des mots dans ta phrase. "et niveau maintenant " : tu voulais dire quoi ?
[^] # Re: Problème de clés ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance MYSQL. Évalué à 3.
L'intérêt des triggers c'est que ça permet une implémentation beaucoup plus transparente de tes règles de gestion. Un développeur n'a pas à connaitre des dizaines de procédures stockées, et savoir quand il doit appeler une procédure ou quand il peut faire une requête directe sur la table. Avec un triigger, il fait son insert sans se soucier de rien du tout, et tout se fait automatiquement.
Et on peut mettre aussi les applications au même plan que le développeur. Imagine plusieurs applications qui attaquent la même base (ça arrive très souvent dans les moyennes et grosses boites). Imaginons donc que l'on ait, en reprenant mon exemple, à ajouter un champs qui est calculé à l'insertion ou modification d'un enregistrement. Si je fais ça dans une procédure stockée, je vais devoir modifier aussi toutes les applis pour qu'elles appellent la procédure stockée plutôt que de faire leur insert. Avec un trigger, pas besoin, ça sera transparent pour elles.
Note qu'un trigger peut appeler une procédure stockée. Et qu'une procédure stockée reste toutefois utile pour les problèmes plus complexe que de simple opération à exécuter sur des changements sur une table ou autre.
[^] # Re: Problème de clés ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance MYSQL. Évalué à 3.
On peut aussi faire de la duplication d'informations (mais pas trop :-)). Par exemple, on affiche une liste de discussions, et on veut afficher pour chacune d'elles le nombre de reponses. Plutôt que de faire un count pour chaque discussion et/ou des group by , on pourrait mettre un champs qui contient le nombre de réponse, ça évite d'avoir à le "calculer" à chaque fois, ça évite les jointures. Certes, ça fait pas très propre pour un puriste, mais d'un point de vue pragmatique, ça permet d'améliorer les perfs.
Et puis en mysql 5, on peut aussi utiliser les triggers. Alors si on doit effectuer des modifications sur d'autres tables quand on en modifie une, utiliser les triggers. ça évite de faire X requetes "à la main", et sera bien plus optimisé au niveau execution (et puis le code client sera plus propre). les triggers ça permet aussi de garder une cohérence dans le schema sans avoir toutes les rêgles de gestion en tête. Par exemple, lors de l'insertion d'une réponse dans la base, le trigger ira faire un update du champs "nombre de reponse" sur la discussion ;-).
Bref, essayer d'optimiser au mieux le sql.
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche ODTPHP, l'API PHP pour manipuler des fichiers OpenOffice en version 1.0. Évalué à 2.
Dommage, ils auraient pu developper des plugins pour un moteur de template existant (au hasard, jtpl ou smarty), cela leur aurait fait un peu moins de boulot, tout en profitant des fonctionnalités de ces moteurs (parce que bon, leur langage de templating est plutôt super limité, pas de gestion de cache etc...).
[^] # Re: Annulée...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Soirée de lancement de Firefox 3.5. Évalué à 3.
[^] # Re: nous
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Soirée de lancement de Firefox 3.5. Évalué à 5.
# Etna
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Un éditeur XML Wysiwyg passe au libre. Évalué à 10.
Non, pas toutes, il y avait le projet Etna, que j'ai commencé à développer il y a presque 5 ans. Entièrement libre, basé sur Mozilla (qui possède un bon moteur de rendu, et des fonctions d'éditions mais que j'ai du quand même hacker). http://etna.disruptive-innovations.com
Malheureusement, faute de temps, il n'est pas encore prêt pour une utilisation en production, et je peine à trouver du temps (surtout depuis que je ne suis plus chez disruptive innovations) pour finaliser une nouvelle version qui contient un nouveau validateur RelaxNG temps réèl plus costaud, et basé sur un gecko plus récent...
Sinon, pour répondre à certaines questions, faire du XML wysiwyg (ou plutôt de l'édition "visuel" d'un document XML, sans que l'utilisateur ait à écrire/à voir du XML), c'est plutôt compliqué, voir plus compliqué que de faire un éditeur HTML wysiwyg.
Quand l'éditeur connait en natif le format XML, (genre Kompozer pour (x)html, ou OpenOffice pour odf), on peut "cabler" en dur des comportements pour tel ou tel balise, voir même à la limite transformer le document XML en un truc binaire qui serait plus facilement exploitable par le moteur de rendu et d'édition.
Mais quand il s'agit d'un éditeur générique, c'est à dire qu'il puisse éditer visuellement n'importe quel type de document XML, ça se complique. Il faut d'abord fournir à l'éditeur un schéma pour qu'il puisse faire de la validation, qu'il sache quel element on peut créer et où, et vérifier le contenu textuel que l'on insère dans ces éléments... Mais ce n'est pas suffisant, car l'éditeur doit pouvoir savoir comment afficher ces balises, si par exemple ce sont des balises qui représente des blocks, ou si ce sont des élements "inlines" (comme le strong en XHTML par exemple.) Malheureusement, il n'est pas possible de fournir ce genre d'informations dans les formats de schemas existants (XMLSchema ou RelaxNG, et puis DTD, on oublie hein).
Il n'est pas possible non plus d'indiquer quel est le contenu par défaut quand on crée tel élément. L'éditeur peut éventuellement le deviner à partir du schema, mais quand il y a plusieurs choix possibles, ben il prend le premier, qui n'est pas forcément celui que veut l'utilisateur...
Manque aussi tout ce qui est descriptif. Un éditeur XML générique, il ne sait pas ce qu'est la balise P en XHTML. Et indiquer "inserer un P" à l'utilisateur, ça va pas beaucoup aider ce dernier. Il faut donc un moyen de dire à l'éditeur que P, c'est un "paragraphe", afin que l'interface soit intuitive. Il faut aussi apporter des descriptions pour que l'utilisateur puisse faire son choix quand, lorsque pour créer un élément, il y a plusieurs choix autorisés par le schema.
Bref, il n'y a rien de prévu dans XMLSchema et RelaxNG pour les éditeurs. Il faut donc fournir ces informations, en plus du schema.
Dans Etna, ça passe par des balises supplémentaire dans RelaxNG (c'est autorisé par la spec RelaxNG) pour tout ce qui est nécessaire à l'édition proprement dite. Et pour ce qui est de l'affichage, il faut fournir une feuille CSS.
Il y a aussi des problèmes d'interfaces utilisateurs. Même dans un document XML orienté textuel, il y a des éléments contenant des informations "techniques" (des metas datas, ou le titre du document par exemple). Là encore, l'éditeur wysiwyg ne peut pas deviner la nature de ces éléments. Et il est préférable que ces informations soient édités avec une interface dédiés. Il faut donc que l'éditeur fournisse des "hooks" pour pouvoir lancer par exemple une boite de dialogues pour éditer ces choses (genre dans open office, la boite de propriété du document). Bref, il faut fournir des éléments d'interface graphique à l'éditeur. Dans Etna, ça passe donc par la réalisation d'une extension (à la firefox) (et la feuille de styles CSS cache les éléments qu'il faut pas éditer via la zone d'édition) .
Enfin, pour les questions à propos de l'utilité d'un editeur XML "wysiwyg", posez vous alors la question : préféreriez vous éditer un document open-office "à la main" avec VI ? Pensez vous que cette méthode d'édition serait plus pratique pour madame michu pour écrire son courrier ? Pour ma part, je dis non. L'utilisateur en à la limite rien à foutre du format. Ce qu'il veut, c'est écrire son document le plus simplement du monde, et que ce document puisse être ensuite utilisé correctement par d'autres outils éventuels (l'éditeur doit produire du XML valide etc.)
Mais maintenant, un éditeur XML wysiywg n'est pas fait non plus pour éditer n'importe quel type de fichier XML. Ca reste bien entendu utile que pour les formats XML orienté documents textuels (docbook, xhtml, odf et j'en passe). Ça n'a bien entendu aucun sens d'éditer par exemple un fichier de configuration XML avec ce genre d'outils. Pour ce genre de document, c'est plus une interface utilisateur graphique qu'il faut, pas une surface de rendu/d'édition textuelle.
Enfin il faut savoir qu'il y a pas mal de domaines et d'industries, où des documents textuels sont stockés en XML, et dans un format XML qui leur ait propre parce que mieux adapté à leurs besoins et parce que leur système d'information a été conçu avec ce format.
J'ai l'exemple d'ailleurs de Rice University (qui commanda le projet Etna), qui stockent leurs cours dans leur propre format XML, et qu'ils publient ensuite sur le web (après transformation via XSLT). Et les gens qui éditent ce genre de document avaient voulu une sorte de traitement de texte, plutôt que d'apprendre le markup du format, ou d'utiliser ces éditeurs XML arborescents et peu pratique finalement pour ce genre de documents... (et malheureusement, suite à l'ouragan catherina, leur budget a été restreint, et n'ont pas pu continuer à financer le projet Etna...)
Enfin pour conclure, les éditeurs XML wyiwyg, c'est comme pour les browsers ou les éditeurs HTML wysiwyg : y en a très peu en open source, parce que ça demande des compétences spécifiques, ça demande de la recherche (donc du temps, donc des sous) parce que c'est un domaine complexe (tant au niveau technique qu'au niveau interface utilisateur), et qu'il y a peu d'expériences "publiques", de feedback, pour aider à leur réalisation.
[^] # Re: HTML oui, CSS non
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Email Standards : les standards du web dans l'email ??!?. Évalué à 2.
Bref, oui à CSS dans les mails.
[^] # Re: Les onglets...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 3.
Sinon non, ils n'ont pas disparu. Une extension qui a foutu le bazard ? Ou une préférence comme dit juste au dessus...
[^] # Re: Et le futur
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 3.
De plus, mettre des choses "à coté", ça existe déjà, ça s'appelle des plugins, (ou des extensions pour les fonctionnalités utilisateurs). Et on voit bien ce que ça donne : c'est la grosse merde. (un seul est arrivé à s'imposer, flash).
Or, l'intégration des plugins dans une page est très limité. On est quand même vachement bridés sur ce qu'on peut en faire (du point de vue du développeur web).
Et il y a qu'à voir tout ce qu'on peut faire maintenant avec la balise video, qu'on ne pouvait absolument pas faire avec un plugin de lecture video classique, quel qu'il soit. cf les demos ici : http://people.mozilla.com/~prouget/demos/
Et pourquoi c'est possible avec la balise video ? parce que le moteur de rendu a le contrôle entier sur l'affichage, il peut modifier l'affichage de la video (à partir par exemple des filtres svg qu'on lui donne, ou des styles css et cie)... Ce qu'il ne peut absolument pas faire via les plugins, puisque ce sont les plugins qui décident ce qui doit être affichés.
Bref, l'intégration des technologies dans un même environnement permet beaucoup, beaucoup plus de choses que d'assembler des trucs divers qui fonctionnent chacun dans leur coin.
Maintenant, je vois pas non plus pourquoi on ne pourrait pas avoir des applications web quasi aussi fonctionnelle que celles que l'on a sur le desktop, sous prétexte que ça allourdi les navigateurs.
Mais tu manques de cohérence dans ton discours. Tu es contre ce progrés. Mais alors je me demande pourquoi tu n'es pas resté avec Netscape 4 sur ta machine hein.
Pour finir, tu trouves que le navigateur devient un bloatware : ça tombe bien, on a jamais assez de contributeurs. On t'attend sur les newsgroup de Mozilla pour en discuter et pour que tu nous proposes des solutions (qui soient réalisables bien entendu). Et je ne te dis pas ça méchamment ou autre : je suis sérieux. Viens donc proposer tes solutions techniques (avec un minimum de crédibilité, c'est à dire en sachant comment fonctionne un moteur de rendu web en gros).
[^] # Re: Consommation mémoire ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 6.
pas du tout (ça fait quand même 6 ans que je bosses avec/sur Mozilla). Firefox, ce n'est que quelques fichiers XUL et js au dessus de XulRunner, lui-même au dessus de Gecko. Ce n'est pas Firefox qui gère les processus ou autre, c'est Gecko. Gecko est plus qu'un moteur de rendu, c'est tout un ensemble : moteur de rendu + couche reseau + couche d'abstraction du système + gestion des processus etc... Bref, tout ce qui est systeme/technique/rendu. Tu lui adjoint ensuite un toolkit XUL, et des composants utilitaires (fichiers, système de mise à jour etc), ça te donne XULRunner. À ça tu y ajoutes des composants spécifiques à ton appli, des fichiers XUL/JS et autre, ça te fait une appli : Firefox.
Actuellement, Gecko ne permet pas de charger un fichier HTML/XUL dans un processus différent. Ce n'est pas en modifiant quelques fichiers XUL et composants de Firefox qui vont permettre de le faire
>tu dis qu'il est impossible de réécrire les millions de ligne mais que les developpeurs sont en train de faire le multi-process, ce qui est bien la preuve que c'est possible d'avoir une architecture correcte sans tout réécrire
Si l''architecture de Gecko aujourd'hui, permet de developper le multi-process sans avoir à tout réécrire, c'est parce que Gecko évolue sans cesse. L'idée du multi process dans Gecko n'est pas nouvelle, ça fait plusieurs années que les core-developpers y pensent (cf sur les newsgroup de Mozilla). Aujourd'hui, il reste encore beaucoup de boulot, et ils sont quand même une petite équipe à temps complets pour y travailler. ça va représenter des patchs énormes quand même. Quand je dis, "sans tout réécrire", il faut relativiser en ayant en tête les millions de lignes de codes Mozilla...
>c'est que quand Chrome est sortie cela a mis en lumière que l'architecture de FF était pourrie..
non, raté. ça juste mis en lumière l'idée qu'il est intéressant d'exploiter aujourd'hui le multi processing dans les browser, grâce à la généralisation des processeurs multicoeurs, mais aussi de l'usage que l'on fait aujourd'hui d'un navigateur.
[^] # Re: Et le futur
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 2.
ce dont je suis sûr en tout cas, c'est que tu es de super mauvaise foi
>Je sais pas pour vous, mais moi j'ai un "vieux" monocore à la maison.
et alors ? un vieux monocore sait lancer plusieurs processus non ? à moins que tu ais DOS comme OS... ou un 286 comme proc..
Jusqu'à maintenant, Gecko n'utilise que des threads, ce qui n'est pas suffisant, et ne permet pas d'isoler chaque page. L'utilisation des processus permet de le faire, et donc si une page "plante" (à cause, par exemple de flash qui part en sucette), ça n'impactera pas sur le navigateur.
>API OpenGL: c'est pour avoir une vraie partie de Unreal Tournament en arrière-plan de la page pendant que tu lis le blog des joueurs!
Il y a des sites qui ont besoin d'afficher des choses en 3D, et pas forcément des jeux (je sais pas moi, genre un site educatif qui montre un truc en 3D).
Bref, fait une recherche sur le web, tu as plein de truc pour faire du 3D dans une page web. Malheureusement, c'est du pur JS, c'est lent, et ça n'utilise pas l'accélération de ta carte graphique.
une API 3D, c'est une VRAIE demande de pas mal de développeurs web.
Et ça permettra, entre autre, aux développeurs de jeux de se passer de flash...
>J'imagine le futur de demain:
Ben non, tu l'imagines mal. Bien au contraire, et parce que Firefox pourra mieux utiliser les capacités de ta machine, que ce soit au niveau de l'utilisation des processus ou de l'accélération matériel de ta carte graphique, il n'y aura pas besoin d'avoir une machine plus puissante pour faire la même chose qu'aujourd'hui en mieux et plus rapide.
[^] # Re: Géolocalisation
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 3.5 est sorti. Évalué à 4.
[^] # Re: Thevideobay
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox 3.5 est sorti. Évalué à 2.
[^] # Re: Consommation mémoire ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 10.
L'architecture de Gecko n'est pas toute pourrie. Elle est très bien et elle évolue depuis 10 ans, même si elle a ses défauts (comme toute architecture).
Sans dénigrer nullement le formidable travail de l'équipe de Chrome, c'est "facile" (entre guillemet, parce que faire un navigateur, c'est tout sauf facile) pour eux d'avoir une architecture différente et adaptée au matériel d'aujourd'hui : ils n'ont pas eu à gérer un passif de 10 ans, ils n'avaient pas de développeurs occupés à maintenir des versions précédentes. Ils avaient toutes leurs ressources focalisées sur le développement de leur navigateur. (sans compter qu'ils avaient déjà une bonne partie du boulot de fait : le moteur de rendu Webkit).
Et pour créer leur navigateur, ils pouvaient se dire : "alors voilà, aujourd'hui les contraintes matériels et OS, c'est ceci cela, la concurrence ils proposent ça et ça mais pas ça. On pourrait donc proposer ceci-cela à nos futurs utilisateurs. Mettons nous au travail."
Faire le même raisonnement en essayant de se projeter 10 ans en avant : c'est tout bonnement impossible (10 ans, c'est une éternité dans le monde informatique). Et dans 10 ans, l'équipe de Chrome aura le même problème que Mozilla : faire évoluer l'architecture de leur produit en tenant compte des évolutions matériels/logiciels/utilisations, mais aussi de la base utilisateur actuelle, c'est à dire pas tout casser d'un coup (les extensions par exemple). Sans perdre non plus des contributeurs qui n'arriveraient peut être pas tous à suivre un changement radical dans le code (que ce soit en temps d'adaptation de compétence sur le code, que d'acceptation de ce changement etc)
Bref, changer d'architecture, ça se fait pas en un claquement de doigt. Et une architecture, ça n'est pas forcément "pourri". Ca dépend du contexte, de l'objectif et de bien d'autres choses.
Et je trouve que les core-developpeurs de Gecko s'en sortent plutôt pas mal jusqu'à maintenant.
Sinon pour ton information, le multi-processus dans Gecko est dans le pipe [1], ça commence même à fonctionner. [2]
Et à priori, ça pourra se développer sans tout casser (ils pensent même trouver un moyen qui éviterait de trop casser les extensions agissant sur les pages web). Comme quoi, l'architecture de Gecko, elle n'est pas si pourrie que ça.
1: https://wiki.mozilla.org/Content_Processes
2: http://blog.mozilla.com/cjones/2009/06/21/multi-process-fire(...)
# Et le futur
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 9.
- implémentation de XBL2 (spec W3C qui attend deux implémentations avant de passer en recommandation) et qui fera exploser le web :-)
- le support multiprocesseur (un processus par tab etc...)
- API 3D sur la balise canvas (API reposant sur openGL, et en cours de spécifications avec Khronos Group)
- les animations SVG (déjà en partie dans le trunk)
- toujours plus de propriétés CSS
Et j'en passe...
http://xulfr.org/news/2009/06/28/283-de-la-3d-dans-gecko
http://ljouanneau.com/blog/post/2009/06/26/Chantiers%3A-XBL2(...)
[^] # Re: Support natif d'Ogg, Vorbis et Theora
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 3.
http://ljouanneau.com/blog/post/2008/10/16/L-element-video
et pourquoi il n'y aura pas de support DirectShow et Quicktime dans Firefox : http://ljouanneau.com/blog/post/2009/06/23/Pas-de-support-Di(...)
Vive Theora !
[^] # Re: Consommation mémoire ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 7.
Pour tester les extensions, les developpeurs ont entre autre une extension, leakMonitor, pour savoir qu'est ce qui leak dans leur code.
Note que tout ces outils ne datent pas d'hier, et sont utilisés/améliorés depuis pas mal d'année.
[^] # Re: Euh....
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Quand Google se fiche de Linux / When Google muck about Linux. Évalué à 2.
et alors ?
Qu'est ce que tu as contre les versions communautaires ?
[^] # Re: Also also featuring...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de PHP 5.2.10. Évalué à 1.
Et puis ça apporte plein d'autres problèmes que je n'ai plus en tête, à tels point que de l'aveu même des core-developer de PHP, safe_mode c'est du vent, c'est de la fausse sécurité et ça sera supprimé dans PHP6.
[^] # Re: Ça passe très bien :)
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 5.
[^] # Re: Sont nul
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 10 000 dollars à gagner, à condition de désinstaller Firefox. Évalué à 2.
L'un des développeurs de Mozilla, Benjamin Smedberg, vient d'annoncer le projet Electrolysis, qui consiste au développement des processus par tab :
http://benjamin.smedbergs.us/blog/2009-06-16/electrolysis-ma(...)
La page du projet est là https://wiki.mozilla.org/Content_Processes et j'en parlais déjà sur xulfr il y a plus d'un mois : http://xulfr.org/news/2009/05/07/278-support-de-processeurs-(...)
Et il ne faut pas croire que Mozilla ne fait que se réveiller maintenant. C'est un projet qui a demarré il y a quelque temps déjà, et c'est le résultat de plusieurs réflexions qui ont eu lieu ces dernières années, voir les discussions sur les newsgroups (bah ouai, ce genre de concepts, ça date pas d'hier). Parce que bien évidement, ce genre de chose nécessite de ré architecturer certaines choses dans Gecko, qui ne sont pas anodines du tout. Et cela nécessite donc aussi du temps et des ressources. D'où le retard sur ce domaine là par rapport aux autres.
[^] # Re: Sont nul
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 10 000 dollars à gagner, à condition de désinstaller Firefox. Évalué à 3.
En cherchant un minimum, il y a quand même plusieurs sites proposant des fontes TTF gratuites.
> Le but de Firefox et de Mozilla, c'est d'avoir une base d'utilisateurs importante, sinon toutes les tunes de la vente de la barre de recherche a Google, elles disparaissent. Donc au moment de choisir les fonctionnalites a implementer, une grosse partie de la decision prend ca en compte. Entre refaire l'UI pour une meilleure ergo ou implementer SVG ou SMIL, le choix est vite fait.
bon, alors, une petite info, parce qu'à priori, tu n'es pas au courant (mais chuuut)
1) il semble que Mozilla ait assez d'argent maintenant pour s'auto-financer (les intérêts gagnés sur les sous mis de coté suffisent à faire vivre la boite)
2) Quand on regarde l'interface de Firefox 3.5, on remarquera quand même qu'il n'y aura pas de grand révolution pour l'utilisateur, entre la 3.0 et la 3.5. La plupart des développements ce sont fait principalement sur Gecko, avec l'implémentation de nombreuses features issues de standards. cf https://developer.mozilla.org/en/Firefox_3.5_for_developers , que tu devrais lire.
Car tu verras que SMIL et SVG, ce n'est pas si plus important que tout ce qui a été fait. Et tout ça en parallèle au développement de SMIL, puisque finalement quelque jours après la création de la branche pour Firefox 3.5, le patch pour SMIL était balancé dans le trunk (mais pas assez terminé, testé et cie pour être dans la branche FF3.5)
Enfin bref, après la lecture de https://developer.mozilla.org/en/Firefox_3.5_for_developers , affirmer que Mozilla ne fait pas grand chose sur les standards, qu'ils sont en retard et cie, c'est grandement exagéré.
[^] # Re: Sont nul
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 10 000 dollars à gagner, à condition de désinstaller Firefox. Évalué à 6.
Maintenant, il me semble qu'en terme de support des standards et autres technologies, ils restent encore loin derrière gecko, webkit et opera. Super, il supportent CSS2.1 complètement par rapport à d'autres (Gecko...), mais bon, ils ne font que rattraper leur retard, et ils en ont encore à rattraper.
>Le coup des fontes telechargeables, paye toi ta mauvaise foi. Il y a pas si longtemps, y avait rien du tout dans Mozilla, forcement tu pouvais moins la ramener.
Mauvaise foi à demi quand même. Ils ne supportent pas ttf, mais juste un format qu'ils ont créé, non standardisé (bon, c'est vrai, en même temps, le W3C n'en a pas voulu).
Bon mais on va pas faire la bataille de celui qui implémente le plus de chose en CSS, à ce jeu là, Webkit ou même Gecko gagnent à coup sûr.
>Quand Firefox va se faire coiffer au poteau sur l'implementation du prochain test acid, tu vas venir nous expliquer que bon, y a des trucs plus prioritaires, hein. Et puis le support des standards, ca passe apres la base d'utilisateurs...
Qu'il y ait des trucs plus prioritaires que passer le test acid, en effet, c'est le cas. Par contre, il ne me semble pas avoir dit que les standards passent après la base d'utilisateurs (en tout cas je n'ai pas compris ce que tu voulais vraiment dire par là).
Il y a des standards, c'est un enjeux, c'est l'objectif de Mozilla, et cela l'a toujours été. Mais il y a des standards plus prioritaires que d'autres. FF3.5 ne passe pas le test acid3 complètement. Mais les points qui ne passent pas encore concernent principalement les animations SVG, qui sont déjà implémenté en partie dans la version trunk de Firefox. Les animations SVG, c'est bien, mais le support de la balise video, ou des trucs comme le offline, JSON, le drag and drop, la geolocalisation etc (1) sont un poil plus important, surtout dans cette époque où les internautes deviennent de plus en plus itinérant, utilisent de plus en plus la video etc. Et malheureusement, Acid3 ne teste pas ces trucs là... Comme quoi, les tests Acids ne démontrent pas tout...
Alors bon, si un jour IE dépasse Firefox en terme de tests Acid, tant mieux pour eux. Mais ils ont encore plus de boulot que Mozilla...
(1) https://developer.mozilla.org/en/Firefox_3.5_for_developers
[^] # Re: Sont nul
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 10 000 dollars à gagner, à condition de désinstaller Firefox. Évalué à 6.
Des boulets je vous dis.