Laurent J a écrit 2948 commentaires

hey, c'était vendredi hein... Aucun humour...

PostgreSQL [1][2], la base de données libre la plus avancée du monde

Oh la la, le troll gros comme une maison ! Dans un journal en plus ! Et MySql 5.1 alors ?? hein ??

Quand il dit "Et la MoFo annonce qu'elle ne veut plus de Thunderbird ? ", il n'exprime pas une pensée, il fait une affirmation. Or ici dans l'histoire, il ne s'agit pas de la MoFo, mais de la MoCo. CQFD.

Comme je l'ai dit plus bas, ce n'est pas une nouvelle fondation, mais une nouvelle company. La fondation Mozilla chapotte toujours, à priori, le projet thunderbird.

Ça me chatouille aussi, et je me suis posé aussi la question. Et je n'ai pas trouvé d'arguments convaincants (ou peut être n'ai-je pas trop compris) dans les explications des pontes de Mozilla sur leurs blogs.

Ils auraient effectivement très bien pu faire deux départements distincts au sein de la company, avec chacune leurs propres budget, leurs propres équipes de dev, leur propre directeur de département. Il y a peut être d'autres raisons qui m'échappent genre peut-être des raisons fiscales, ou des raisons au niveau du statut de la company, <mode parano>ou une stratégie sur le long terme dont on nous parle pas...</mode parano>.

Oui, surtout qu'en plus, pour commencer ils donnent 3 millions de dollars à la nouvelle compagnie qui s'occupera de développer Thunderbird.

Ensuite, il ne faut pas confondre la fondation et la compagnie. Si j'ai bien tout compris, ce n'est pas la fondation qui se "débarrasse" de Thunderbird, mais la compagnie. En fait, maintenant la Mozilla Company devrait s'appeler la Firefox Company :-)

Enfin bref, tout ça pour dire que la fondation Mozilla chapotte maintenant deux compagnies : Mozilla Company et la "Mail company" (elle n'a pas encore de nom).

Et tout ça pour dire aussi qu'on n'est pas encore Vendredi, et qu'il faudrait vraiment qu'on puisse moinsser les journaux trollesques qui colportent de fausses informations.

Toi tu n'as pas dû participer au developpement d'une plateforme de blog pour dire ça...

Je cotoie quasie quotidiennement (par IRC) les développeurs d'Overblog (une autre plateforme de blog), et de temps en temps ceux de Skyblog, et je peux t'assurer que ce genre d'application, ça ne se résume pas à afficher du texte qui est dans une BD. Il y a quand même énormément de choses à développer. C'est d'autant moins simple que ce genre d'applications ont plusieurs centaines de milliers d'utilisateurs, et donc où la prise en compte de la sécurité et des performances est primordiale. Ce qui ne facilite pas le développement, et nécessite des compétences d'experts.

Tiens, pour t'en convaincre, regarde un peu le code de dotclear 2 (qui peut être utilisé pour faire une plateforme de blog)

Et puis pour finir, un blog, ce n'est rien qu'un CMS spécialisé, tout comme l'est Mediawiki. Donc niveau complexité, à fonctionnalité équivalente (en terme de gestion de droit, de commentaire, d'édition etc..) ça se vaut...

si, tout à fait. Mais il s'agit juste du langage et de certains objets de base.

Par contre ce qui n'est pas standardisé, c'est l'api que propose le navigateur en javascript. Par exemple l'objet window, xmlhttprequest etc.. Il y a aussi l'api DOM (document &cie), qui est standardisé, mais soit les navigateurs l'implemente mal, ne la respecte pas (genre IE), soit il y a des propriétés / méthodes en plus pour apporter plus de fonctionnalité, et qui peuvent être spécifique au navigateur.

pas de problème non plus avec mon firefox 3a...

On s'en fout. T'as qu'à ouvrir un site chez free pour y ouvrir une tribune.

Je connais en effet une boite qui fait de la cartographie à base de SVG. : 3liz.com.

Et ils utilisent Gecko comme plateforme pour leurs applis et pour afficher leurs cartes SVG. Et même si le support SVG n'est pas extraordinaire d'un point de vue performance, ça reste largement utilisable.

Aussi, ceux qui râlent contre firefox + SVG, faudrait d'abord analyser ce qui plombe les perfs dans la page en question. Je n'ai pas regardé, mais si ça se trouve les scripts de cette page sont codés avec les pieds, tant au niveau Javascript, qu'au niveau SVG. En effet, SVG est plutôt riche, et comme dans tout langage, il y a des bonnes et des mauvaises façons pour créer les dessins.

Le temps ?

laisse tomber, on est vendredi...

>Les développeurs d'openoffice sont des bénévoles? Les principaux contributeurs du noyau sont des bénévoles?

Non, c'est pour ça que le logiciel n'est pas gratuit.

M'enfin, Daniel aurait du préciser le contexte : celui de Mozilla. On s'est posé toutes ces questions suite à certaines annonces de Mozilla. Et elles prennent toutes leur sens dans le contexte actuel de la politique de Mozilla.

M'enfin je vais pas développer, pas le temps.

Chez dedibox, tu as 5go de backup gratos..

Et dans thunderbird tu as la possibilité de stocker en local les messages d'une boite imap, pour consultation offline.

Bref, je pense que tu devrais soit changer de client mail, soit regarder plus attentivement la configuration de celui que tu utilises :-p

1) pour le diff, je trouve qu'il est pas tip top : on a pas la différence au niveau caractère, or c'est une fonctionnalité très utile, on voit tout de suite ce qui a été réellement modifié. Donc si tu veux un diff qui soit mieux, tu peux utiliser la classe diff qu'il y a dans jelix (que tu trouveras dans lib/diff/ dans une des archives de jelix, http://jelix.org ), elle provient de phpwiki, mais j'ai fait quelques corrections pour que ça passe dans PHP5 sans problème.

2) Pour le parsing de wiki, tu peux utiliser wikirenderer (http://wikirenderer.berlios.de ) : c'est un parser de syntaxe wiki dont tu peux totalement paramétrer la syntaxe et le comportement sur chaque tag wiki. L'avantage de wikirenderer, c'est que ça produit du code XHTML valide à coup sûr, que c'est hautement configurable (tu peux générer autre chose que du xhtml), et que pour toi, tu n'as pas à réinventer la roue (vu que je vois que ton parser wiki ne supporte pas encore tout).

Bon c'est sûr que tout ça, ça va légèrement augmenter le poids de ton script, mais il n'en sera pas moins simple à utiliser ;-)

Tout à fait

en plus certains hebergeurs proposent non seulement un espace pour le backup, mais aussi un serveur de mail secondaire (qui stocke les mails qui arrivent, au cas où ton serveur de mail crash). (dedibox par exemple).

Linux Weather Forecast indique les évolutions dans un futur proche. Mais qu'en est-il d'une éventuelle version 2.8, voir 3.0 ? Y a t-il de grands changements prévus à l'horizon justifiant la sortie de ces versions majeures ? Ou dans trois ans, en sera-t-on encore sur une 2.6.x, genre 2.6.82 :-) ? (ce n'est pas une critique hein...)

Le départ des 2 dev principaux n'est un drame. Nul n'est irremplacable.

Oui un pisseur de code lambda dans une SSII est remplaçable. Mais ici il ne s'agit pas de deux pisseurs de code, il s'agit de deux types qui connaissent à fond le produit, qui ont dirigé le projet avec leur vision, qui ont permis à thunderbird de devenir ce qu'il est devenu.

Donc non, désolé, ils sont irremplaçables. La preuve : il n'y a personne pour les succéder. Et celui qui va les succéder (un jour...), il va mettre pas mal de temps à "s'approprier" le projet, à en connaitre les moindres recoins. En attendant, l'avancement du projet va beaucoup en souffrir à mon avis. Et dans un cas comme ça, en général un projet prend du retard vis à vis de la concurrence, de l'innovation etc...

Cette affirmation "nul n'est irremplaçable", n'est franchement pas valable sur des projets "pointus".

ah ah bien tenté !

Ayant déjà bossé en environnement Mainframe, et ayant vu ce que pouvait donner du code COBOL sur des applications énormes de plusieurs millions de lignes (applications de l'ex boite d'assurance UAP), c'est à dire avec du code spaghetti de partout à force d'évolutions dans tout les sens et des habitudes des "vieux" codeurs sur les premiers COBOL (hein ? les procédures ? c'est quoi ? vive les GOTO !), je m'interroge beaucoup sur votre transcodeur. Le code COBOL du projet NACA est si propre que ça ? bien structuré et tout ? pour arriver à faire du transcodage parfait ?? Pas un seul GOTO nulle part ? (il me semble qu'on ne peut pas faire des goto en Java)

J'imagine que ça n'a pas du être une mince à faire que de faire ce traducteur de code...

Vivement le prochain n'épisode :-)

> J'ai personnellement beaucoup de facilités avec des langages type SQL, et beaucoup de difficultés avec la manipulation d'arbre de donnés avec des boucles. J'adore jouer avec le premier et déteste me farcir le second exercice.

As-tu déjà jeté un coup d'oeil à la gestion d'arbres par représentation intervallaire ?
http://sql.developpez.com/arborescence/

En clair : plus besoin de faire des boucles dans tous les sens pour récupérer une arborescence. Une seule requête suffit. Seul bémol : la modification de l'arbre (insertion, suppression de noeud) est un poil plus compliqué qu'un simple insert ou delete, mais je trouve que c'est plus supportable que de récupérer une arborescence.

Il me semble aussi qu'il existe une extension pour postgresql qui permet de gérer des arborescences.

> Tu veux dire que les classes sont reconstruites automatiquement dès qu'on modifie le schéma ?

oui

> Même si c'est désactivable, je trouve ça génant dès qu'on travaille à plusieurs.

Je ne vois pas en quoi c'est génant. jDao et en particulier CopixDao (vu la jeunesse de Jelix :-) ), a été utilisé sur de nombreux projets de plusieurs développeurs depuis des années, ça n'a jamais posé de souci.

>Ton dernier argument sur la taille n'est pas un critère pour moi.

Et pourtant, c'est un argument important. Vu que PHP reparse les sources à chaque requête HTTP, ça fait une grosse différente au niveau tenue du serveur en charge. Si tu utilises un cache d'opcode (APC), la différence sera moindre, mais il y en aura quand même une : la quantité de mémoire nécessaire pour stocker l'opcode (plus le programme est gros, plus il prend de la mémoire dans sa version compilé, logique..). Et même si l'utilisation du framework est déstiné à un site à faible trafic, cela peut aussi faire une différence en hébergement mutualisé.

>74 fichiers/681ko pour propel

pardon, cela ne concerne que le générateur de Propel. Il faut donc y ajouter les 37 fichiers/246ko du runtime :-) (parmis les 6 fichiers de jDao, il y a le runtime et le générateur)

Ok, je viens de revoir Propel, je l'ai en effet confondu avec des trucs comme Doctrine. Le principe général de jDao est effectivement similaire à Propel. Bien que jDao soit plus vieux que Propel (c'est une évolution de CopixDao, utilisé dans le projet Copix qui fut l'un des premiers framework PHP), il est un peu moins "puissant" sur certaines choses, comme la gestion des relations n-n. Mais il propose d'autres particularités en contre-partie. Par exemple dans jDao (et si je ne me trompe pas dans ce que j'ai vu dans propel):

* On peut déclarer dans le fichier XML des méthodes et indiquer les critères de ce qu'elles devront récupérer, effacer ou mettre à jour. Cela évite de devoir générer la requête à coup d'objet Criteria comme dans Propel : les requêtes sont donc en dur dans la classe générée.
* jDao suit le design pattern DAO
* Un objet DAO peut être mappé sur plus d'une table
* Pas de génération explicite des classes : dés qu'on modifie le fichier XML, les classes sont regénérées (on peut désactivé cette vérification de mise à jour en prod).
* Un fichier XML par objet mappé, et non pas tout dans un seul fichier. Chaque module contient donc ses propres fichiers XML jDao. Cela facilite l'installation de modules tiers. (peut être qu'il est possible d'avoir plusieurs fichiers avec Propel, mais j'ai pas vu)

Enfin jDao est plus léger que Propel (6 fichiers/81ko, contre 74 fichiers/681ko pour propel), même si il est vrai qu'il a un peu moins de fonctionnalités. Mais ce qu'il permet de faire couvre déjà pas mal des besoins AMHA. Et des améliorations sont prévues dans les versions à venir.