dans un monde idéal. Mais un éditeur de logiciel ne va pas attendre 4 ans que la nouvelle Debian sorte pour avoir le paquet officiel de la dernière version de XulRunner.
Et pourquoi le ferait-il? En quoi utiliser une version forkée de xulrunner change-t-il quelque chose à cela? Ou bien le problème est-il pour l'éditeur de logiciel d'attendre que Mozilla ne release une nouvelle version de xulrunner ? Côté éditeur, on peut soit packager une nouvelle version de xulrunner soi-même, soit compiler son paquet statiquement. On fait des trucs similaires dans ma boite. Si au contraire c'est Debian qui veut la nouvelle version de Thunderbird, elle se débrouillera pour fournir un package du dernier xulrunner.
Non, ils doivent la modifier, parce qu'ils ont des besoins spécifiques que ne fourni pas le XulRunner standards.
Il ne faut pas voir XulRunner comme une lib classique, mais comme une plateforme, un framework embarquable.
Comme Qt, qui fournit QtQuick, Webkit, un client HTTP, un environnement de scripting javascript et plein d'autres trucs. Qt n'est pas une lib classique, c'est une plateforme, un framework embarquable. Est-ce pour autant que tout le monde forke et patche ? Non. Il s'agit juste de faire en sorte que la plateforme fournisse tout ce qui est nécessaire, et d'ajouter ce qui manque pour avoir une plateforme satisfaisante pour tous les usages, et réduire d'autant les coûts de maintenance des différentes applications.
Si ce n'est pas possible, c'est que xulrunner n'était pas le bon framework pour développer l'application. Si c'est suite à un manque de volonté de la part de Mozilla, tout pareil.
Je sais que Mozilla assume pleinement le fait que xulrunner est avant tout la plateforme de Firefox et refuse d'implémenter des choses qui ne sont pas dans l'intérêt immédiat de Firefox. Il n'y a pas de problème intrinsèque avec cela, il faut juste alors arrêter de promouvoir xulrunner comme une plateforme de développement généraliste.
Et ce genre de situation arrive souvent dans les projets XulRunner conséquents, que j'ai vu passé.
Pourquoi cela n'arrive-t-il pas avec les éditeurs basés sur webkit ? Peut-être est-ce un problème de design ou de modularité du moteur gecko, ou de refus d'ajouter des fonctionnalités qui ne sont pas directement nécessaires à Firefox (bien que avec les nouveaux webdev tools…) ? D'un autre côté, j'imagine mal un truc comme sunbird ou thunderbird nécessiter une modification du moteur de rendu. Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.
Toutes les applications ne sont pas forcément packagées, et encore moins pour toutes les distros ou versions de distros. Donc l'utilisateur devrait utiliser le XulRunner proposé dans sa distro, bien souvent incompatible pour les applis complexes (surtout celles qui contiennent des composants binaires)
Non, c'est un raccourci malsain, car comme dit plus haut, le fait de pouvoir le faire n'implique pas qu'on ne peut pas faire autrement. On peut distribuer une appli compilée statiquement, et de toute façon le problème est le même pour les dépendances déjà présentes dans la distro (cairo, gtk+, libx* et toutes les autres). Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.
[^] # Re: à propos de XulRunner
Posté par nud . En réponse au journal Une histoire de fork. Évalué à 3.
Et pourquoi le ferait-il? En quoi utiliser une version forkée de xulrunner change-t-il quelque chose à cela? Ou bien le problème est-il pour l'éditeur de logiciel d'attendre que Mozilla ne release une nouvelle version de xulrunner ? Côté éditeur, on peut soit packager une nouvelle version de xulrunner soi-même, soit compiler son paquet statiquement. On fait des trucs similaires dans ma boite. Si au contraire c'est Debian qui veut la nouvelle version de Thunderbird, elle se débrouillera pour fournir un package du dernier xulrunner.
Comme Qt, qui fournit QtQuick, Webkit, un client HTTP, un environnement de scripting javascript et plein d'autres trucs. Qt n'est pas une lib classique, c'est une plateforme, un framework embarquable. Est-ce pour autant que tout le monde forke et patche ? Non. Il s'agit juste de faire en sorte que la plateforme fournisse tout ce qui est nécessaire, et d'ajouter ce qui manque pour avoir une plateforme satisfaisante pour tous les usages, et réduire d'autant les coûts de maintenance des différentes applications.
Si ce n'est pas possible, c'est que xulrunner n'était pas le bon framework pour développer l'application. Si c'est suite à un manque de volonté de la part de Mozilla, tout pareil.
Je sais que Mozilla assume pleinement le fait que xulrunner est avant tout la plateforme de Firefox et refuse d'implémenter des choses qui ne sont pas dans l'intérêt immédiat de Firefox. Il n'y a pas de problème intrinsèque avec cela, il faut juste alors arrêter de promouvoir xulrunner comme une plateforme de développement généraliste.
Pourquoi cela n'arrive-t-il pas avec les éditeurs basés sur webkit ? Peut-être est-ce un problème de design ou de modularité du moteur gecko, ou de refus d'ajouter des fonctionnalités qui ne sont pas directement nécessaires à Firefox (bien que avec les nouveaux webdev tools…) ? D'un autre côté, j'imagine mal un truc comme sunbird ou thunderbird nécessiter une modification du moteur de rendu. Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.
Non, c'est un raccourci malsain, car comme dit plus haut, le fait de pouvoir le faire n'implique pas qu'on ne peut pas faire autrement. On peut distribuer une appli compilée statiquement, et de toute façon le problème est le même pour les dépendances déjà présentes dans la distro (cairo, gtk+, libx* et toutes les autres). Un cas particulier ne devrait pas servir de justification pour une mauvaise pratique généralisée.