Faire un don ! | | style | statistiques | charge serveur | contactez-nous | plan | lettre d'information

Liens connexes

Dépêche modérée par

Dépêche éditée par

Code : Apple ouvre le CVS de WebCore

Posté par Philippe Fremy (page perso). Modéré le mercredi 08 juin.
Apple
Suite à la mauvaise presse faite à Apple parce qu'elle ne « jouait pas le jeu » avec la communauté du libre, notamment les développeurs de KHTML, Apple a décidé d'ouvrir complètement le CVS et la base de données de bugs de leur moteur web, WebCore, et d'être plus réceptif.

> Lire l'article (56 commentaires, moyenne: 2.1).

Le feuilleton commence lorsque Apple annonce qu'il utilisera KHTML pour Safari et WebCore, son moteur HTML.

Après un an, à l'occasion de l'annonce par David Hyatt du succès de Safari au test Acid2, les développeurs de KHTML se plaignent à voix haute que Apple ne communique aucun patch, que leur CVS n'est pas ouvert, que leurs modifications sont inexploitables pour KHTML et que Apple prend mais donne finalement peu à la communauté.

L'histoire fait un peu de bruit et serait remontée jusqu'à Steve Jobs. Deux développeurs de KHTML ont été invités dans les locaux de Apple pour discuter avec le management et les directeurs puisque Apple n'était pas satisfait de la situation. Toutes les demandes de KDE ont été exaucées :
- ouverture du CVS de WebCore
- ouverture de la base de bugs de WebCore
- ouverture d'un portail open source pour WebCore

De leur côté, les développeurs de KDE ont réussi à faire rentrer dans KHTML une partie des patchs de Safari (mais ça a demandé beaucoup de travail), de sorte que Konqueror passe maintenant aussi le test Acid2.

Bref, tout a l'air d'évoluer dans le bon sens pour les relations KHTML / Safari.

Évidemment, on souhaiterait que KHTML et Safari n'utilisent qu'une seule base de code, mais ce n'est pas possible. D'une part Safari est développé en Objective C, et d'autre part les développeurs de Safari ont besoin d'avancer tellement vite qu'ils n'ont pas le temps de s'intégrer proprement à KHTML.

L'ouverture de la base de bugs et du CVS devrait cependant permettre aux développeurs de KHTML de réintégrer les évolutions de Safari dans de bonnes conditions.

Notons que le retour côté Apple semble déjà positif puisqu'on peut lire sur la page de WebKit :
The response so far has been incredible. We've gotten lots of people building and testing, and we've already had lots of bug reports and even some patches.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

L'ascenseur

Posté par gaolinn le 08/06/2005 à 13:11. (lien). Évalué à 10.

Preuve qu'une grosse boîte proprio peut renvoyer l'ascenseur si la communauté le demande avec force et conviction.

[ Répondre ]

Nuance

Posté par JRM le 08/06/2005 à 13:20. (lien). Évalué à 10.

"Après un an, à l'occasion de l'annonce par David Hyatt du succès de Safari au test Acid2, les développeurs de KHTML se plaignent à voix haute que Apple ne communique aucun patch"

Oui mais non, Zack Rusin s'est surtout plaint des utilisateurs beuglant sur le devs de khtml parce qu'ils n'intégraient pas les modifications de Safari. Il a donné les raisons de cette non-intégration mais ne s'est aucunement plaint d'Apple.

[ Répondre ]

>D'une part Safari est développé en Objective C

Posté par oops (page perso) le 08/06/2005 à 13:34. (lien). Évalué à 1.

Il ne me semble pas que Safari soit inclus dans le WebKit.
Le WebKit est le coeur de Safari.

D'autres part Objective-C++ ( berk ) devrait être inclus dans gcc-4.1
ce qui permettra à KDE d'utilser l'Objective-C et à GNUstep d'utiliser le C++ ...

[ Répondre ]

des avantages du code source ouvert...

Posté par Paul POULAIN (page perso) le 08/06/2005 à 13:36. (lien). Évalué à 10.

The response so far has been incredible. We've gotten lots of people building and testing, and we've already had lots of bug reports and even some patches


J'ai mal compris ou bien ils viennent de découvrir qu'une multitude d'yeux qui testent et examinent le code source seront toujours plus efficaces qu'un nombre limité et qui plus est en interne ?

Si ca pouvait leur donner des idées pour d'autres trucs, ce serait pas mal ;-)

[ Répondre ]

[+] L'ascenseur

Posté par gaolinn le 08/06/2005 à 13:52. (lien). Évalué à -10.

Preuve qu'une grosse boîte proprio peut renvoyer l'ascenseur si la communauté le demande avec force et conviction.

[ Répondre ]

[+] ca fesai longtemps

Posté par Philou Kapouik le 08/06/2005 à 13:57. (lien). Évalué à -6.

et oui ca fesai longtemps qu on avait pas entendu parler d apple ...

comme quoi c est vraiment la revolution chez eux ...



--
Software is like sex: it's better when it's free

[ Répondre ]

A noter pour ceux qui comme aurait l'idée en tête

Posté par support linux (page perso) le 08/06/2005 à 14:20. (lien). Évalué à 6.

Il existe un projet visant à porter webcore vers GNUSTEP et à partir de ce moteur créer une API libre d'interfaçage avec le moteur.

https://gna.org/projects/gswebkit/(...)

Le projet semble mort actuellement. Autre chose, ils ont fait le boulot de séparer le code C++ du code Objc ; au vu des avancés de gcc je ne suis pas sûr que ce travail est un intérêt autre que la compatibilité avec gcc 3.x (ce n'est pas si négligeable en fait : ) ).

Je ne l'ai pas testé l'ayant découvert cette semaine : je ne sais donc pas le niveau d'avancement du projet.


NB: Comme quoi, avant de se lancer dans un projet, il faut tourner 7 fois sa recherche sur google.....

[ Répondre ]

[+] L'ascenseur

Posté par gaolinn le 08/06/2005 à 14:42. (lien). Évalué à -5.

Preuve qu'une grosse boîte proprio peut renvoyer l'ascenseur si la communauté le demande avec force et conviction.

[ Répondre ]

Ca marche pas...

Posté par equi le 08/06/2005 à 15:21. (lien). Évalué à 4.

... enfin chez moi ça ne marche pas en tous cas : Safari plante dès que j'essaie de lui faire passer le test acid2

Ici il y en a qui ont réussi à le valider ?

[ Répondre ]

[+] Si Apple voulait vraiment faire un effort...

Posté par revponpuneq le 08/06/2005 à 16:11. (lien). Évalué à -6.

Apple donnerait des infos sur le matériel, qu'on puisse faire fonctionner tout ce qu'on veut si on choisit d'y faire fonctionner Linux...


--
Eric Bachard

[ Répondre ]

raisons du fork

Posté par Antoine le 08/06/2005 à 21:18. (lien). Évalué à 3.

Je ne comprends pas du tout la remarque suivante :

Évidemment, on souhaiterait que KHTML et Safari n'utilisent qu'une seule base de code, mais ce n'est pas possible. D'une part Safari est développé en Objective C,

On parle bien de WebCore, pas de Safari. Si WebCore est développé en C++ (logique puisqu'il s'agit d'un fork de KHTML), en quoi le fait que Safari est en ObjectiveC a-t-il la moindre influence ?

Sinon :

et d'autre part les développeurs de Safari ont besoin d'avancer tellement vite qu'ils n'ont pas le temps de s'intégrer proprement à KHTML.

On voit le clash entre logique d'entreprise (course aux features, à l'intégration précipitée de trucs douteux) et logique du libre (temps choisi, développement durable). Ou encore : compagnonage contre expansionnisme commercial.

[ Répondre ]

Revenir en haut de page