Laurent J a écrit 2948 commentaires

>et qui prend en charge certains traitements de PHP, accélérant donc le fonctionnement.

pardon, il faut lire "certains traitements de Jelix"

Je ne connais pas très bien symfony, donc difficile de te donner une comparaison complète. De ce que je connais de symfony, il semble que cela soit un framework plus lourd que Jelix (en terme de ligne de code et temps d'execution). M'enfin faudrait faire des benchs sérieux pour voir.

Cependant, il y a quelques points que j'ai regardé, et sur lequel je pense que Jelix est supérieur. Par exemple, propel ou doctrine c'est bien, mais ce sont des trucs énormes, voir bloatware. En effet, les trucs à la activeRecord "redécouvrent" à chaque requête http le schema d'une table ou d'une base de donnée et inclus donc tout un mécanisme pour générer entièrement les requêtes SQL dynamiquement, à chaque fois qu'il faut faire une requête SQL. (bien que les implémentations tentent de mettre des systèmes de cache un peu partout dans leur code, mais c'est à mon sens plus des bouts de scotch qu'autre chose).

Ça a un intérêt en développement, c'est même sexy à utiliser, mais c'est, pour moi, un truc complètement contre productif dans un environnement en production, une fois que le site est en ligne, dans la mesure où à partir de ce moment là, les schemas des tables ne bougent plus. Partant du constat que la façon la plus performante de faire des requêtes est de les écrire en dur dans le code (ou quasi en dur, puisque généralement on a des paramètres), jDao a été crée en ce sens, tout en évitant au développeur d'écrire des trucs rébarbatifs, voir même du code non sécurisé (puisque jDao génère du code qui est tient compte des problèmatique de SQL injection). À partir d'un fichier qui décrit le mapping (fichier qui peut être généré par une ligne de commande), jDao, à la première execution, génère une classe une bonne fois pour toute, avec des requêtes en dur dans le code de cette classe, comme si tu avais fait toi même la classe métier et écris toi même les requêtes. jDao est ainsi plus léger et permet au framework de ne pas avoir à "redécouvrir" à chaque execution de page la structure d'un enregistrement ou autre. À noter cependant que jDao n'est peut être pas encore aussi puissant que doctrine ou propel, mais je pense de toute façon que son principe de fonctionnement est plus interressant au niveau des performances.

Et j'ai essayé d'avoir la même philosophie dans les autres composants de Jelix : tout est fait dans jelix pour que l'application soit performante, et pour éviter autant que possible, d'une part d'avoir des traitements qui sont inutiles dans un context de production comme je viens de l'expliquer, et d'autre part d'avoir du code mort (des trucs jamais utilisé par l'applis mais toujours chargé), y compris du code qui serait propre à une version de PHP (donc qui serait "mort" pour d'autres versions de PHP): tu peux te construire un framework jelix optimisé pour ta version de PHP, tu as même une édition "GOLD" qui inclus une extension PHP à installer sur le serveur, et qui prend en charge certains traitements de PHP, accélérant donc le fonctionnement.

Et je rajouterai que ce n'est pas par hasard si Jelix a été choisi par les développeurs de la plateforme over-blog, sur laquelle plus de 5 millions de pages sont lues par jour (et même plus, ce chiffre est vieux), et hébergeant plus de 630 000 blogs.

Bon après, en dehors des considérations sur la performance, un framework se juge sur les possibilités qu'il offre par rapport à ses propres besoins dans ses projets (il y a aussi une part de "feeling", vis à vis de la manière dont on créer une application avec tel ou tel framework). Et ça, il n'y a que toi qui puisse faire la part des choses, et donc, plutôt que de lire mon argumentation qui pourrait de toute manière toujours être prise comme totalement partiale et subjective :-), le mieux est que tu ailles voir un peu les quelques tutoriaux pour te faire une idée du truc.

Le problème est que j'ai choisi de mettre la doc dans un wiki, pour que des contributeurs puissent aider facilement à la rédaction. Mais j'ai pas trouvé de wiki qui me convienne, et qui permette de générer un PDF à partir de tout une arborescence de pages.

Mais je note ta requête :-)

Effectivement, je trouve que les fichiers donnés par AMD manquent cruellement d'explications et de commentaires. Deux simples listes de registres, c'est maigre.

M'enfin c'est toujours ça, et probablement que ceux qui ont déjà fait les drivers libres pour ces cartes, ça leur est moins cryptiques qu'à nous. Et que ça va leur permettre au moins de corriger et de compléter un minimum leur code source.

>Son "travail remarquable" est fait en restant conformablement assis dans sa chaise

Ce qui est faux. Et encore moins vrai pour les ouvrages qui ont suivi. En même temps, il ne faut pas oublier que c'est l'un des premiers à avoir réfuter la thèse officielle, quelques mois seulement après l'évènement. Et il faut se rappeler qu'à l'époque, aller enquêter sur ce genre de chose n'étaient pas chose aisé. Ensuite, il ne faut pas oublier non plus le climat émotionnel de l'époque : peu de gens étaient prêt à entendre une autre vérité que celle officielle. Aussi peu de journaliste se sont avancés (à l'époque) à essayer de démêler le vrai du faux, de remettre en cause la thèse officielle (publiquement au moins). C'est moins vrai maintenant. Le problème de Messan c'est d'avoir essayé d'alerter l'opinion publique sur un truc "trop frais". Et tout le monde s'est foutu de sa gueule. Et ce qu'on remarque aujourd'hui, c'est que les avis sont bien plus partagé, que des nouvelles zones d'ombres sur cette affaire sont apparues, et que finalement, globalement, il n'avait pas forcément tord.

De plus hoaxbuster réfute (il y a très longtemps tu noteras) les arguments de Messan avec des arguments qui ont été eux aussi largement contre attaqué par d'autres. Y a qu'à voir, depuis, tous les avis divergents de plusieurs scientifiques sur le soit-disant crash d'un boeing sur le pentagone. Qui croire ? C'est plutôt difficile, et finalement, penser que Messan raconte n'importe quoi ou penser que Messan détient la stricte vérité, ce n'est que pure bêtise.

Tu aurais du lire le livre, ça t'aurais éviter d'écrire cette bêtise. Il y a certes pas mal de liens dans le livre, mais il fait aussi ses analyses à partir d'interviews, etc... Après l'adhésion à ses théories est un autre problème. Mais ça en change rien au fait que tu dis n'importe quoi.

Bah il va pas beaucoup en profiter. Dieu l'a foutu dans un logement à l'écart des autres, (juste à coté de celui de la Callas).

http://tourtesmagazine.com/dieu/?p=25

>Simplement hormis FF dédié au Web la cible de javascript me parait limitée

j'ai pris FF et javascript pour un exemple concret d'application qui peut être scriptable. Maintenant embarquer javascript ailleurs, ça te parait peut être limité, mais je ne suis pas de ton avis.

J'ai l'impression que tu confond langage et API. Au niveau langage, javascript est plutôt complet (après on aime ou on aime pas l'objet basé prototype), surtout dans ses dernières versions qui ont des trucs syntaxiques à la python ;-).

Au niveau de l'API, c'est aussi illimité, dans la mesure où, comme avec tout moteur de script embarquables (Python ou autre), tu peux déclarer auprès du moteur, des objets du langage qui seront mappés sur l'API C/c++ interne de ton application, et donc ces objets te paraitront natif du point de vu de ton script. En plus, tu as la liberté de "montrer" ce que tu veux de ton API, donc cela sécurise l'exécution des scripts.

D'ailleurs, il faut faire ce mapping quand on embarque un moteur de script, pour que les scripts puissent interagir avec le logiciel, sinon embarquer un moteur de script n'aurait plus d'intérêt. C'est fait par exemple dans Firefox pour le DOM, l'objet window, xmlhttprequest etc..

(et dans FF, il y a aussi XPCOM/XPConnect pour tout le reste de l'API : cela permet d'étendre l'API javascript très facilement sans toucher à spidermonkey et ce qui l'entoure).

>D'ailleurs il etait question à un moment de pouvoir utiliser python pour étendre FF. C'est tombé aux oubliettes ?

Tu peux faire des XPCOM en python, c'est toujours ça, mais il faut se compiler une version avec le flag qui va bien. Le support n'est pas inclus d'office. (L'IDE Komodo par exemple a toute son API dans des XPCom en Python).

Pour ce qui est de l'utilisation directe de Python dans les pages XUL/HTML, il y avait un travail en cours, mais je crois que ce n'est pas terminé (pas sûr que ce soit très actif en ce moment d'ailleurs). Il me semble que c'est prévu toutefois dans Mozilla 2.

>Tu voulais plaisanter là.

Non. Mais tu ne sembles pas avoir lu ce que j'ai dis. Je parlais des développeurs web.

>Un plugin FF necessite de connaitre le XUL, le js , les CSS et de lier tout ça tant bien que mal sans savoir où on en est.

Ça tombe bien, un développeur web connait le js, le CSS et doit apprendre le XUL qui n'est franchement pas difficile ( pour un bouton, pour un item de menu, oua la vache, c'est compliqué !). Le seul truc sioux, c'est apprendre les API interne, mais heureusement, il y a de la doc.

Maintenant va demander à un développeur web (qui n'a pas forcément voire rarement fait du C++), de faire une extension C++ pour IE par exemple...

>PyQt te permet de créer des applis complètes sans pb sans recourir au c++ par ex.

ouai ouai, c'est beau python. Pas sûr que les applis C++ qui embarquent python intègre PyQT (surtout si elle est pas faite en QT). Relis le sujet du journal, on parle de langage de script "embarqué".

> Pour XHTML, le W3C a virer toute les conneries des versions d'html précédentes (et il y en avait des tonnes).

HUM ! Remplace XHTML par HTML 4.01/strict dans ta phrase, et tu diras la vérité. XHTML 1.0 n'est qu'une simple "XMLisation" de HTML 4.01. (pas de nouvelles balises, ni de nouveaux attributs) et XHTML 1.1 n'apporte que peu de nouveautés.

Par contre l'ex-futur XHTML 2 faisait une remise à plat de la grammaire XML, mais il semblerait que ce soit mort avant même que ce soit terminé : y a des trucs pas cohérent et ça n'intéresse strictement personne, et encore moins les personnes les plus concernées par ce genre de chose : les éditeurs de navigateurs. (aucun ne participe au groupe de travail, sauf MS, et encore, seulement sur le papier, c'est dire...)

Les langages de scripts sont souvent bien plus connu que les langages compilés. Prenons l'exemple de Javascript. Le moindre petit développeur web connait javascript (pas forcément bien mais bon...). Et bien le moindre petit développeur web peut par exemple se faire une petite extension XUL pour Firefox en 2-3 coups de cuillère à pot. Bon j'exagère un poil, mais c'est en tout cas extrêmement plus simple que si il fallait faire l'extension à coup de fonction C/classe C++ (avec tout ce que ça apporte comme lourdeur au dev : installation de X outils de dev, compilation etc.) On en a une preuve flagrante quand on compare IE et Firefox : regardez celui qui a le plus d'extensions disponibles. C'est celui qui peut être étendu avec un simple script.

Et puis je plussois ce que dit pasBillpasGates : un langage de script permet de limiter les dégâts en terme de gestion de mémoire, de limiter l'accés à certaines API internes pour pas faire n'importe quoi, puisque c'est l'interpréteur qui gère ces problémes. Mais ça ne les éradique pas forcément, comme on peut le voir avec certaines extensions Firefox codées avec les pieds, et qui contiennent des leaks dans tous les sens.

>Ce qui prouve qu'il y a eu erreur de la part de Disruptive Innovations de refuser tout développement de la version 1

Ça prouve rien du tout. Et surtout il n'y a eu aucune erreur. Ce sont des circonstances qui ont fait que la poursuite du développement de la version 1 est tombé à l'eau pour nous.

>ce KompoZer mériterait d'avoir le nom nvu-1.7.10

Peut-être, mais NVU est une marque de Linspire, et il n'est pas possible de la réutiliser pour des versions ultérieures de NVU 1.0 sans le consentement de Linspire... (oui je sais c'est dommage mais c'est comme ça et c'est valable même pour nous à DI ).

>vu que toutes les resources de Disruptive Innovations sont maintenant affectées au développement de FullerScreen :(

Je ne sais pas où tu as lu ça, mais sache que c'est totalement faux. J'ai pas l'impression de travailler sur FullerScreen, ou alors serait-ce à l'insu de mon plein grés ? :-). FullerScreen n'est qu'un "petite" extension que Glazou réalise entre deux projets.

En ce qui concerne le développement de Mozilla "nvu2" Composer, c'est vrai que c'est un peu en suspend, mais bon, todo list énorme, clients, autres projets prioritaires, tout ça... (d'ailleurs, au passage, si une entreprise veut bien "sponsoriser" le dev de Composer...).

> Si Firefox est lourd, est-ce à cause de son interface en XUL ?

c'est une cause oui. Mais bon, sur ce genre de machine, il me semble que le opera installé n'est pas la version desktop, mais une version "embarqué", avec une interface spécifique, adaptée pour les petits écrans. Donc au même titre qu'opéra, tu n'utiliseras pas Firefox sur ce genre de machine, mais son accolyte minimo ou maemo (qui n'ont à priori pas d'interfaces en XUL)

>Est-ce que Gecko tout seul est suffisamment léger pour espérer tourner sur une machine lente avec peu de RAM, si on lui fournit une GUI appropriée ?

réponse oui : minimo fonctionne depuis quelques années déjà sur des appareils bien moins puissant que le nokia. (mais le développement de minimo est un peu en suspend depuis quelques mois il me semble).

Mais il est probable tout de même que gecko soit plus lourd que le moteur d'opera.

Je suis pas expert dans lesdits protocoles, mais voila ce qu'il faut faire pour envoyer un message en xmpp à quelqu'un :

<?xml version='1.0'?>
<stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
<message from='expediteur@exemple.com' to='destinataire@exemple.net' xml:lang='fr'>
<body>Hello are you receiving this message ?</body>
</message>
</stream:stream>

Voici le même message envoyé avec IRC :

:expediteur@exemple.com PRIVMSG destinataire@exemple.net :Hello are you receiving this message ?

Quand on calcule le nombre de caractère (je ne compte pas les caractères blanc entre les balises pour xmpp), on a un paquet de 298 caractères pour XMPP contre 97 pour IRC. Soit un facteur 3.

Si on ne compte pas les parties variables (nom des destinataire/expediteur et le message en lui même), on a 214 caractères contre 13, soit un facteur 16 !

Bref, xmpp est beaucoup plus gourmand en bande passante que IRC et demande un peu plus de ressource au niveau du client puisque parser du XML est quand même beaucoup plus compliqué que de parser une commande IRC (m'enfin je chippotte, pour une machine moderne, la différence ne se voit pas, sauf peut être si on est connécté à 20 channels de 150 users en même temps avec des discussions trollesques à gogo).

Maintenant peut être que XMPP permet-il au client d'envoyer directement à tous les autres clients du channel, plutôt que de l'envoyer au serveur qui dispatch ensuite. Dans ce cas, il est probable que les serveurs ne souffrent pas autant que je le dis. Mais je n'ai pas regardé comment ça fonctionne exactement.

Note: c'est amusant^W delirant aussi de voir l'énorme différence entre un ping en XMPP et un ping IRC (envoyé entre client et serveur pour savoir par l'un si l'autre est alive et vice versa).

ouai mais bon au niveau occupation de bande passante, il me semble que jabber est largement déficient. Va donc installer un serveur jabber en remplacement de freenode.net... Et offrir quelques milliers de dollars pour installer des machines supplémentaires...

Oui c'est pénible ce genre de formulaire. Heureusement, il y a des solutions, comme Firefox + extension Resizeable Form Fields, qui permet de modifier à la souris la taille d'un élement de formulaire ;-)

https://addons.mozilla.org/fr/firefox/addon/3694

Personnellement, je ne peux plus m'en passer.

> Heuuuu, a quoi ils servent les millions de la fondation mozilla ????

À payer les dizaines de développeurs qui bossent non pas sur Firefox, mais sur Gecko (la plateforme quoi) ;-) Les 11 de Firefox sont ceux qui bossent exclusivement sur l'interface et les composants propres à Firefox.

Et puis il y a ceux qui bossent sur les serveurs (download, addons etc..), ceux qui bossent sur developer.mozilla.org, ceux qui bossent sur le triage de bug etc.. Et puis y a le marketing, les confs etc... Et puis y a des sous qui vont au financement des "succursales" de Mozilla à travers le monde, aux deplacements des contributeurs pour les confs etc..

Renseigne toi sur le fonctionnement de XulRunner avant de le comparer avec n'importe quoi.

Et puis les applications qui patches XulRunner sont des cas très particulier, et je n'ai jamais dis que c'était une généralité.

> Une extraction permettrait de faciliter les mises à jour, je suppose...

Justement non, c'est pas si simple que ça, parce qu'il faut gérer les dépendances. Si je met à jour XulRunner n à n+1 (parce que telle appli le demande), comment vont se comporter les applis installées qui l'utilisent ? Y a de fortes chances que la plupart se vautrent (incompatibilité binaire si elles ont des composants binaires, incompatibilité des API etc...).

Une solution serait de maintenir la majeure partie de l'API avec des interfaces freezées mais c'est très couteux en maintenance et complique les évolutions dans XulRunner pour les devs de Firefox. Une autre serait de permettre l'installation de plusieurs versions de xulrunner, mais c'est pas simple, surtout sur windows si je ne dis pas de bêtises. Et ne parlons pas du fait que des logiciels majeures comme joost et songbird ont hacké xulrunner dans tout les sens pour intégrer des trucs très spécifiques, donc un xulrunner "commun" ne leur serait d'aucune utilité.

Maintenant, si tu penses avoir des solutions faciles pour gérer ce genre de chose, tu peux en parler à Benjamin Smedberg (qui a réalisé XulRunner). Je ne te cache pas que ça arrangerait beaucoup de monde, mais hélas, cela n'est vraiment pas aussi simple que tu le dis.

encore une fois, ce n'est que pure spéculation de ma part, et il est fortement probable que j'ai sous estimer les coûts et donc que "4 ans" soit exagéré. Faut savoir lire des fois...

>C'est marrant que d'autres projets comme debian ou gentoo arrivent à s'en tirer avec un budget approximativement nul (pour gentoo, je suis moins sûr pour debian).

Ouai genre, les devs vivent d'amour et d'eau fraiche. Et puis les machines, les serveurs, les sites web, tout est gratuit et ça ne coûte rien à personne. Qu'est ce qu'il faut pas entendre comme connerie tout de même...

>Et puis avoir en caisse de quoi fonctionner 4 ans à plein sans la moindre rentrée d'argent,

C'est juste une spéculation de ma part, je l'ai précisé il me semble : ce n'est en aucun cas un fait établi, je suis pas dans le secret de la compta de la MoCo, et il est fortement probable que j'ai largement sous-estimé les coûts.

Faut arreter de gober tout comme un gamin et de prendre pour argent comptant.

>Mais oui ils sont plus productifs que les gars de chez Mozilla, peut-être parce qu'ils ne se trainent pas un monstre à moitié en XUL ? ça doit aider.

Franchement, c'est de la connerie pure et simple. Genre les mecs de chez Mozilla foutent rien. Suit un peu les commits juste pour te rendre compte du boulot effectué.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&mo(...)

Et ce n'est que la partie visible de l'iceberg, parce que derrière y a tout l'aspect "review" des patchs qui prennent beaucoup de temps, l'aspect gestion de bugs aussi (il y en moyenne 100-150 qui débarque dans le bugzilla, dont certainement le tiers sont des duplicatas, des bugs invalides etc ce qui fait perdre énormément de temps).

Et puis renseigne toi un peu, tout ce qui a trait à XUL represente quedal au niveau temps de dev par rapport au reste (évolutions dans le layout engine par ex, dans l'API etc).

>La question que je me pose c'est comment puis-je faire - en tant que simple utilisateur - si je veux que de vieux bugs de thundebird tombent enfin dans les oubliettes de la préhistoire de Mozilla Corp.

Rechercher le bug en question sur http://bugzilla.mozilla.org, et voter, laisser un commentaire confirmant le problème dans le cas où il n'est pas confirmé...

>Pour eux, un contrat de 50 euros, c'est surement trop peu pour s'y attarder

Je confirme, c'est pas avec ça qu'on va pouvoir mettre un steak dans notre assiette. Surtout que la majorité des bug ne se corrigent pas en 1 heure, mais nécessite plusieurs jours de dev :-)


>Existe-t-il un moyen - je pense à un genre de cagnote - qui permettrais de récolter de l'argent pour résoudre ce genre de petits bugs ?

Non, y a pas à ma connaissance. Tu peux filer un don je crois, mais c'est pas sûr que ça sera investi directement dans la résolution d'un bug précis. Et puis ça peut être pervers comme système : la priorité des bugs serait alors faite sur ceux où il y a plus d'argent, et pas forcément ceux qui sont les plus importants (aux yeux de la MoCo). Genre y a des bugs très techniques qui sont important à résoudre, mais que l'utilisateur lambda en a rien à fiche ou qu'il ignore tout simplement, et donc sur lequel il y aurait peu de "mises".

Établir la priorité des bugs en fonction des désiratas des utilisateurs et des objectifs de la Moco, c'est déjà un casse tête sans fin dans le système actuel, alors si il y a en plus de l'argent en jeu...

Un des interêts de webrunner est d'avoir une interface minimum qui ne "perturbe" pas l'utilisateur. Par exemple, pour une appli web en intranet, ça peut être trés intéressante car on peut un peu mieux contrôler ce que peut faire l'utilisateur : il n'a pas de bouton back par ex. Et puis ça donne un look un peu plus pro. Et pour peu que l'interface de ladite application web soit en XUL, ça ressemble à une appli desktop.