Laurent J a écrit 2938 commentaires

>Mais Akrogen n'a pas la prétention de ré-implementer Mozilla

Donc ce n'est pas du XUL. Tu ne dois donc pas appeler ça du XUL.

Quand tu veux parler d'une renault megane, tu n'appelle pas ça une 307, bien que ce soit toutes les 2 des automobiles, avec 4 roues, 1 moteur, un volant...

On pourrait dire pareil pour C# ou Java. Ça se ressemble sur certains points, mais on n'a pas appelé ça avec le même nom.

En clair : trouve un autre nom pour ce langage XML.

Cela aurait été bien de ne pas appeler ce langage XML de description d'interface "XUL". Je rappel que XUL est un langage de Mozilla (XUL est d'ailleurs une TM de Mozilla), et le pseudo XUL de Akrogen n'a que quelques similitudes avec le XUL de Mozilla, d'après ce que j'en vois : des attributs et balises propres à akrogen, et une implémentation vraiment très partielle du XUL de mozilla d'après la doc de référence

Bref, cela ne fait qu'apporter confusion chez les développeurs, c'est dommage.

ce que tu décris ressemble fortement à jDao dans le framework Jelix.

Tu as juste un fichier dans lequel tu déclares sur quelle tables et quelles propriétés l'objet dao sera mappé. Tu peux aussi decrire des methodes : nom, type (select, update...), les propriétés à prendre en compte, les conditions etc..

Et jDao te compile tout ça sous une forme de classe PHP, avec toutes les méthodes qu'il faut et que tu as décris, contenant alors les requêtes SQL correspondantes. Cette classe est mise en cache (donc pas de recompilation à chaque appel). le fait que les requêtes soient déjà générée et le code mis en cache apporte des performances respectables pour un orm.

je vois deux gros inconvénients à cette méthode :

1) c'est super lourd. Même pour un petit aquarium comme ça (j'ai presque le même à la maison). Pour le déplacer rempli, c'est galère.

2) changement des pièces /maintenance : faut tout essuyer (l'huile c'est galère à essuyer), surtout les contacts j'imagine, quand on branche/rebranche un truc. Sans parler qu'on s'en fout plein les mains.

une raison pour ne pas prendre une dedibox : ils mettent des semaines en ce moment à livrer. Un ami en a commandé une le 17 avril. On attend toujours. Et bien sûr, impossible d'avoir une date approximative (c'est tellement trop dur de faire date aujourdhui + temps livraison pieces + nombre de serveur commandés * temps de preparation d'un serveur...)

si ça un rapport : je t'indique juste que le premier avantage que tu indiques dans ton commentaire précédent n'est pas valable puisque PDO le fait déjà.

Je n'ai pas dit par contre que PDO faisait ce que tu décris dans le deuxième avantage.

le fetch object de php renvoit 1 seul et unique object par tuple. Cette objet à ma connaissance n'embarque aucune méthode, et récupère en propriété tout les champs du tuple

Utilise PDO disponible dans php5 : tu peux indiquer la classe à utiliser pour l'instanciation des objets (donc indiquer tes propres classes).

pour le 1) : relis ton histoire de france (et la constitution qui n'est pas totalement claire sur le sujet quand même). Le président actuel n'est pas le premier à agir de la sorte. Et je dirais même que la majorité des présidents de la république ont suggérés à leurs premiers ministres de proposer tels ou tels ministre. Il y a juste que certains (chirac par ex) sont plus "discrets" que d'autres.

Bref, on a une présidence "forte", et ce n'est pas la première fois...

> C'était une question.

Désolé, mais je l'ai lu comme une supposition. Comme ta phrase ci dessous d'ailleurs : tu supposes qu'ils ne font rien à ce propos alors que c'est faux. En ce qui concerne les retours sur FF3, cela ne t'auras pas échappé qu'il n'en est encore qu'au stade alpha, et qu'il est alors bien imprudent d'annoncer quelconque malfaçon comme tu le fais ci-présent.

>Faire un break dans l'implémentation de nouvelles fonctionnalités pour se concentrer uniquement sur ces problèmes seraient une très bonne chose je pense.

Il y a pratiquement des personnes qui ne font que ça. Et franchement, je ne vois pas en quoi les deux types de développements (optimisations/newfeatures) serait incompatibles. De toute façon, il y a des corrections de bugs qui nécessitent des compétences spécifiques que n'ont que très peu de personnes. Alors pendant que les personnes concernées corrigent les bugs/leaks profonds, les autres devs (payés ou bénévoles) font quoi ? ils se tournent les pouces ?

devenir une usine à gaz ? non du moment que ce qu'il propose est réèllement utilisé et bien implémenté. C'est pas parce qu'il y a plein de fonctionnalités que c'est une usine à gaz.

Pour le suivi du rythme et en ce qui concerne Konqueror : trés honnetement, si apple n'avait pas pris khtml comme moteur, il ne serait pas là où il en est, même avec toute les bonnes volontés de l'équipe khtml. Les grandes avançées dans le moteur Khtml sont dues aux developpements qu'ont fait les devs d'apple, si je ne raconte pas de bêtises. Mais ce n'est pas forcément négatif. Apple fait parti du WHATWG, donc en principe implémentera toutes les nouvelles features liées au moteur dans webkit, que pourront alors reprendre les devs de khtml pour intégrer dans Konqueror. Je ne pense donc pas que les jours de Konqueror soient comptés.

Pour une meilleure intégration de Firefox dans KDE, faudrait que quelqu'un travaille sur l'intégration de qt comme toolkit dans Gecko. Il fut un temps où ça marchouillait, mais je crois que c'est un peu à l'abandon de ce coté là effectivement. http://lxr.mozilla.org/seamonkey/source/gfx/src/qt/
http://lxr.mozilla.org/seamonkey/source/widget/src/qt/ (et il faudrait travailler sur d'autres composants pour mieux communiquer avec KDE, genre le clipboard, le wallet etc)

>Je ne vois pas non plus comment ferait un primo-arrivant sur le marché du navigateur.

Si tu remarques bien, ce fait n'est pas nouveau. depuis combien d'années il n'y a pas eu de "grand" navigateur ? Ou plutôt de nouveau moteur de rendu web utilisé par un des principaux navigateurs ? pas loin de 10 ans ? (le dernier doit être khtml non ? et ça fait combien d'années qu'il a débuté ce projet ?)

ba demande aux developpeurs web 2.0 ce qu'ils en pensent de toutes ces nouveautés ;-) C'est pas tant une question d'urgence, qu'une question d'avancer. Il FAUT faire évoluer la plateforme web, si on ne veut pas que les applications web migrent vers des trucs proprio comme silverlight ou flash/apollo. Car il est clair que si la plateforme web ne répond pas aux besoins des développeurs, ils finiront par migrer vers d'autres technos, d'autres plateformes (vers toujours plus de facilité, de possibilité etc..)

Bref, finalement si, c'est une urgence.

Et en tant que simple utilisateur, tu as aussi à y gagner : des applis/sites mieux conçu, plus légèrs, offrant plus de possibilité etc...

C'est chiant ces complaintes à répétition à propos des leaks and co. Et c'est encore plus chiant de voir ces suppositions de fuites mémoires sur des choses que tu n'as même pas encore testé.

Les devs Mozilla y travaille dur sur ces problèmes, qui ne sont pas évident à résoudre vu la complexité du code. M'enfin dans Firefox 3, les choses devraient s'améliorer car de nombreuses améliorations ont été fait en ce sens, notamment l'intégration d'un cycle garbage collector &cie, la deCOMtamination de certains objets du coeur (ce ne sont plus des XPCOM, mais ça je dirais que ça améliore plus la performance que corriger des leaks ) etc..

dans un navigateur, tu as ce qu'on appelle un "cache", qui comme son nom l'indique, met en cache les pages web que tu visites.

Encore mieux : tu as généralement une fonction "Offline" sur ton navigateur, qui te permet de surfer... offline. (seulement sur les sites qui sont dans le cache bien évidement).

Encore mieux mieux : les specs des nouvelles fonctionnalités offlines, proposent plein de petites choses qui permettent d'informer le navigateur ou l'application des capacités offline de l'appli.

Par exemple, quand l'utilisateur met son navigateur offline ou online, un evenement dom est généré. L'appli en cours peut alors être informé du passage et agir en conséquence. Par exemple, gears, si il voit que le browser est offline, mettra les nouveaux mails en attente d'envoi, en les stockant en local via une autre api, Storage (dans firefox, c'est du sqlite derrière), plutôt que de tenter de les envoyer directement sur le serveur. Et au passage en online, gears est informé, donc peut alors faire la synchro avec gmail, envoyer les mails en attente etc...

Au niveau de l'appli, une page web est très souvent liés à des feuilles de styles, images et d'autres fichiers, qui ne sont pas forcément chargés tout de suite par le navigateur. Avec les nouvelles possibilités, il est possible d'indiquer avec la balise link, les ressources qui doivent être absolument stockées en locales car nécessaire pour le mode offline. Ces ressources peuvent être notamment d'autres pages web de l'application.

http://xulfr.org/news/2007/02/14/199-application-web-offline(...)

Si mozilla et consort ont fait leur truc dans leur coin, c'est bien parce que le W3C est une organisation lourde pour pondre un standard. Et dans un WG du W3C, il y a souvent trop de monde, donc trop de consensus, trop de compromis. Résultat : ça a du mal à avancer.

De plus, pour qu'une recommandation du W3C soit validée, il faut une implémentation du truc. Or il y a des cas où l'implémentation est très difficile (cf certaines propriétés css2), ou possible mais industriellement pas utilisable.

Alors voilà, Mozilla, Opera, Apple ont préféré faire un truc ensemble dans leur coin (le fameux WHATWG), afin d'avancer le plus rapidement possible et proposer des features qui répondent *vraiment* aux besoins des développeurs web actuels. (D'ailleurs le W3C a pris peur et a fini par créer les groupes de travail appformat, webapi ...)

MAIS, cela ne veut pas dire qu'ils vont en rester là. Parce que l'objectif final est tout de même de proposer leurs spécifications au W3C, avec, pour quelques unes d'entres elles, des implémentations qui fonctionnent et qui montrent que les specs pondues, ce n'est pas que des trucs tordues sortis tout droits de la tête de savant fous.

D'ailleurs parmis les specs proposées au W3C, il y a déjà la spec xmlHttpRequest et XBL2 qui sont sur le point de passer en recommandation...

>Mon navigateur n'est pas un lecteur multi-média.

Tu utilises links ou lynx certainement ? Parce que le mien (Firefox) et plein d'autres (Konqueror, opera , IE ...) le sont comme ça a été indiqué dans un commentaire précédent. Et pour qu'ils le soient completement, il manque effectivement la vidéo.

Et puis peut être que tu vis en 1995 et que tu nous écris à travers Ipot, mais sâche qu'en ces glorieuses années 200x, les sites web font un peu plus qu'afficher de simples textes. Et entre autres choses donc, de plus en plus de vidéos.

Alors maintenant, pourquoi la vidéo ? En résumé d'un billet que j'avais écris il y a quelques temps ( http://ljouanneau.com/blog/2007/04/17/659-la-balise-video )

- balise <video> plus simple à écrire que <object>
- api standardisée pour lancer la lecture, arret, retour, arrière etc.. (ce qui n'existe pas avec la balise object, puisque l'api dépend du plugin)
- meilleure ergonomie : le developpeur ET/OU l'utilisateur peuvent choisir l'interface utilisateur à afficher. Soit les boutons (lecture&co) proposés par défaut par le browser, soit ceux fournis par le dev web (si il n'a pas eu la flemme de le faire). Cela a des avantages coté accessibilité, utilisabilité etc..
- meilleur accessibilité : puisque api standard et semantique -> meilleur controle du contenu par le browser/user
- enfin, format libre proposé par défaut : il y a plus de chance que le contenu puisse être lu (à l'avenir) . De plus puisque format libre, implémentation possible dans le navigateur.


À noter que la balise video est aussi implémentée dans une version expérimentale d'Opera. http://people.opera.com/howcome/2007/video/

c'est certain que tu vas pas faire du word avec ça...

Par contre ça peut avoir des applications dans le monde professionnel dans certains milieux. J'imagine que dans tout ce qui est conception/manipulation 3d, ça peut être utile (imagerie médicale peut être ? genre le medecin qui peut scruter un scan bien plus facilement). Ou encore pour les aiguilleurs du ciel, avec vue en 3D des trajectoires et navigation dans l'espace.

bien sûr, ça serait pas sur une table de salon, mais sur un écran oblique ou vertical. Je suis sûr que ça aura une utilité dans certains domaines spécifiques, où la souris ou autre périphérique de navigation 3D limitent l'ergonomie.

un logiciel utilisant vlc n'est pas forcément multi-plateforme. Le fait que Democracy player repose sur la plateforme Mozilla (utilisée par Firefox) qui fonctionne elle aussi sur de nombreux OS n'est pas étrangé au fait que l'on peut utiliser Democracy player sur plusieurs OS. D'ailleurs il est probable, puisque la plateforme Mozilla et VLC le permette, qu'on puisse compiler DP sur beos, *bsd, win ce, qnx, solaris...

ouai enfin, personnellement, je ne suis pas fan de mettre une plethore de projets dans un même dépot. Les numéros de versions (commits) n'ont alors plus de sens. Un numéro de version est censé representé un état N d'un projet. Si il y a plusieurs projets, alors pour un projet donné, il y a pleins de numéro de versions qui correspondent à un même état de ce projet.

Ça passe pour des projets de 10 lignes qu'on regroupe dans un même dépôt. Pour un projet minimum sérieux, il devrait avoir son propre dépôt.

Un exemple que je trouve justement mauvais est sur le projet KDE : je trouve la gestion de leur dépôt carrément bordélique. Je ne comprend pas l'intérêt de regrouper tous les projets dans un même dépôt. Surtout que subversion permet de lier les dépôts entre eux avec la propriété svn:externals sur les répertoires.

Bien sûr que si... Sinon tu ne pourrais pas utiliser l'application pendant qu'un document se charge par exemple.. Firefox utilise beaucoup les threads.

Je ne sais pas de quel discussion il parle par contre, mais je sais que l'api des threads a été améliorée dans Gecko 1.9/FF3.

si les possibilités de Javascript ne sont pas adaptés à ce que l'on veut faire, c'est qu'alors il faut bien que le browser fournisse des apis plus satisfaisante (au prix d'une plus grosse lourdeur en terme de poids). CQFD.

Ceux qui codent les libs en question, ne le font pas par pure plaisir. C'est bien parce qu'il y a des manques sur les plateformes web.

Tu parles ici des innovations au niveau de l'interface (qui sont appréciables, je n'ai pas dit le contraire). Ce que tu décris ne sont en rien des innovations "technologiques". Moi je te parle de ce qu'il y a dessous le capot (XUL, XBL...). La plateforme de développement quoi.

Permet moi de penser que le zoom "complet", est un "détail". Personnellement, je n'ai pas (encore) besoin de ce genre de fonctionnalité. J'en ai besoin ? hop, j'installe une extension. (m'enfin le zoom est un mauvais exemple à mon avis, car c'est plus un problème du moteur de rendu qu'un problème de fonctionnalité d'interface).

Si opera correspond parfaitement à tes besoins, parfait. Mais sache que ce n'est pas le cas de tout le monde. Chacun a des besoins spécifiques, que ne satisfont pas tous les navigateurs. Un jour tu va vouloir que Opera fasse ceci ou cela. Tu fais quoi alors ? Pas grand chose. Tu prie pour qu'Opera veuille bien implémenter ta feature tant éspérée. Idem pour Konqueror.

C'est là où Firefox fait fort : tu peux construire ton propre navigateur. Soit en installant une extension qui répond à ton besoin, soit en la faisant toi même (un peu de XUL, de javascript, un zip...) (ou en la faisant faire, et pas besoin des devs d'opera/konqueror pour ça).

Mais là où tu te méprends, à mon humble avis, est que pour la majorité d'entre elles, elles existent non pas parce que le navigateur est déficient, mais parce qu'elles répondent à un besoin. Grosse nuance.

D'ailleurs, au sujet de certaines déficiences, la popularité de certaines extensions a fait que cela a fini par être intégré d'office dans le navigateur (exemple, la gestion des onglets améliorées dans FF2). Cela démontre un avantage supplémentaire par rapport aux autres navigateurs : par la popularité de certaines extensions, on sait ce qu'il manque, et cela permet alors d'améliorer le navigateur en ce sens, sans toutefois accepter tout, pour ne pas non plus que Firefox deviennent un monstre.

Si on devait inclure dans firefox les fonctionnalités proposées par les milliers d'extensions existantes, ce n'est plus un browser qu'on aurait, mais un système d'exploitation.

autre remarque

ne va-t-on pas vers l'alourdissement d'un outil qui n'a pour seul but la navigation sur le web.

Nous ne sommes plus en 1995. De plus en plus de site web ne sont pas des sites de consultation, ce sont des *vraies* applications. Les intranets en regorgent depuis longtemps, mais le web en général est maintenant contaminé (aaaah le web 2.0..).

Le but des navigateurs aujourd'hui n'est plus de permettre la simple consultation d'un site, mais est aussi de fournir une plateforme d'execution pour les applications web. Donc avec toutes les API que cela nécessite pour les développements..

Ne pas accepter le fait que le web est en pleine mutation et qu'il y a des nouveaux besoins technologiques, est la mort assurée à moyen terme pour un éditeur de navigateur. (Ce n'est pas pour rien que Microsoft a relancé la machine IE)

Un autre exemple. Pas mal de lib js propose une fonction getElementsByClassName, pour récupérer tous les éléments html qui ont une classe spécifique.

Cette fonction a été implémenté nativement dans Firefox 3.0a. Certes, ça en fait un navigateur un tout petit peu plus "lourd" dans la mesure où il va occuper quelques (kilo?) octets de plus à cause de cette implémentation.

Cependant, quand on lit un comparatif de performances, entre une implémentation native et une implémentation apportée par une lib js externe, il n'y a pas photo : http://ejohn.org/blog/getelementsbyclassname-speed-compariso(...) .

En conclusion, le navigateur le plus lourd, le plus lent, c'est bien celui qui n'implémente pas la fonctionnalité pourtant souvent utilisée par les développeurs web, pas celui qui l'implémente et qui a quelques kilo octets de plus.

il ne se disperse pas du tout. Il s'améliore et suit les besoins du web d'aujourd'hui. Il ne faut pas confondre fonctionnalités d'interfaces (apportées par les extensions qui sont pas mal responsable de la lourdeur d'une interface si elles sont nombreuses), et les possibilités du moteur de rendu (qu'il est difficile voire impossible d'apporter par une extension).

Ici, on parle bien des possibilités du moteur de rendu et de la plateforme, pas de l'interface utilisateur.

L'implémentation de la vidéo (balise <video>), les API supplémentaires pour les applications web (html5, le offline etc), ce ne sont pas des choses que l'on peut apporter facilement par des plugins ou des extensions.

Le constat est simple aujourd'hui : les développeurs web ont besoin que le navigateur apporte certaines possibilités *nativement*, pour pouvoir réaliser plus facilement les applications d'aujourd'hui et de demain, et éviter de demander à leur internautes d'installer tel ou tel plugin pour utiliser leurs sites.

Les spécifications de HTML5 par le WHATWG est une bonne vitrine de ce qu'on a besoin aujourd'hui. Si on veut pouvoir les utiliser, il faut que le browser les implémente (ce qui valide au passage la faisabilité de ces specs). C'est ce que fait Mozilla. Sachant qu'une partie de ces specs est en cours de validation au w3c ou seront proposés plus tard.

Donc il est vrai que les futures browser seront plus lourd (et encore tout est relatif), mais ce n'est pas pour des choses inutiles, et ce n'est pas du tout en dehors du scope web. Il faut bien un jour faire évoluer les langages du web...

Comme je disais, la lourdeur est relative. Un exemple : beaucoup de lib javascript aujourd'hui implémente pas mal de trucs qui améliorent l'API DOM et javascript, de manière à simplifier le boulot des développeurs. Qu'est ce qui te semble le plus lourd ? ces libs javascripts, que l'on doit inclure dans chaque page web ? Ou leur implémentation native dans le moteur javascript du browser, ce qui aurait pour conséquence des pages plus légère et des scripts plus rapide ?

Autre exemple : je préfère que mon browser implémente nativement la balise <video> avec un codec theora libre, plutôt que de devoir subir l'installation d'un truc lourd et fermé comme Flash, pour lire simplement des vidéos. Et au final, le browser n'est pas forcément plus lourd (je doute que browser+<video> soit plus lourd que browser+flash)

(Au passage, il y a déjà une version expérimentale de Firefox implémentant <video> http://www.bluishcoder.co.nz/2007/05/support-for-html-video-element-in.html )