Log de ce matin retravaillé pour vous donner le fond du discours de façon un peu plus courte. On parle aussi de l'aspect technique de libwww mais ce qui me semble le plus important est comment ça concerne le côté charte donc je poste ça ici
J'ai pas mal coupé dans le log.
== libwww ==Liria :
Sinon j'ai regardé comment remplacer libwww. Il y a deux approches, bas niveau et plus haut niveau.
Le bas niveau c'est l'équivalent de la bibliothèque libwww, elle te parse le code html reçu, construit les blocs un par un formant la page, en respectant les règles HTML/CSS mais te demande à chaque fois de le dessiner toi même. C'est ce que fait le client (ou je subodore, je reconnais n'avoir pas lu le code en question), il dessine dans un "contexte" (mot informatique pour désigner une surface, disons une fenêtre) OpenGL. Donc dans cette approche, tu as pas mal de travail à faire, globalement tu te charge de toutes la partie "dessiner" le texte, les images les cadres etc...
Cela est logique comme approche surtout dans un contexte 3d. Cependant si on regarde bien, ici la fenêtre WebIG n'a rien de spécial par rapport à la 3d. Finalement c'est une fenêtre 2D très classique.
Revenons à cette bibliothèque, qu'elles sont les équivalents aujourd'hui ? Zatalyz, tu as cité libcurl l'autre jour sur le canal #ryzom, ce n'est pas le cas, même si wikipédia ose dire que libcurl est une version moderne de libwww : ils se sont fourvoyés complètement. Enfin, si, libcurl est une version moderne de libwww mais d'une toute petite sous partie, celle qui a trait à l'aspect communication, transfert HTTP point.
Nous ce qui nous intéresse c'est le moteur de rendu, le moteur capable d'analyse du code HTML et de rendre cela dans une zone "dessin" intégrant les polices, le style CSS, etc... De ce coté, tu n'as pas 36 000 alternatives. Tu as WebKit, la bibliothèque de rendue du projet KDE, qui depuis a évolué et est utilisé pour Safari sous Mac OS X et chrome ou le moteur gecko, celui de firefox.
Cette approche te donne un contrôle très fin sur ce que tu veux faire mais tu as beaucoup de travail, notamment car il te faudra intégrer le tout, ajouter javascript, les polices, les ... etc...
Une seconde approche de plus haut niveau consiste à te simplifier la vie en embarquant directement un "navigateur web" dans ton application. Globalement l'idée démente est carrément d'ajouter le code du navigateur à ton application et le laisser gérer la fenetre webig de A à Z. Tu lui indiques juste la zone de dessin à l'écran, et tu ne t'occupes plus de rien. Tu as alors toutes les fonctionnalités d'un navigateur : javascript, css, etc...
L'avantage de cette approche: tu n'as presque à rien à faire. Le code se résume à définir une surface (bitmap), demander à navigateur de faire le rendu dedans puis tu la prends comme texture et tu la colles dans ton environnement 3d. ( bon faut gérer aussi la souris, le clavier, mais c'est trivial une fois que tu as passé 10 nuits blanches à comprendre pourquoi il faut appeler sans logique apparente telle et telle fonction avant ).
De ce coté je n'ai trouvé que 2 solutions (bon ma recherche est rapide) : intégrer gecko - le moteur de rendu de firefox ou chronium, le moteur opensource de chrome
Les inconvénients : si tu plantes le navigateur web, tu plantes ton application, tu n'as pas vraiment la possibilité de comprendre pourquoi il plante avec les 100 000 lignes de firefox ou chrome. Les bugs de firefox ou chrome deviennent les bugs de sécurité de ton application. ( n'est pas sure pourtant de pouvoir pouvoir débugger le moteur de rendue webkit ou gecko seul). L'avantage tout le travail d'intégration est déjà fait: javascript/css/police/son, etc.... dans le navigateur.
Je reviens sur les solutions.
Mozilla : globalement c'est pas vraiment fait pour permettre de l'intégrer simplement, voir pas du tout, en plus il a son langage XUL de gestion d'interface sur lequel est batit le moteur de rendu. Globalement sur le web : on te dit qu'il faut 30 jours pour intégrer mozilla
Chronium : il doit être plus léger, basé sur webkit, c'est 6 jours de boulot et tu peux aussi profité de la capacité à gérer les fenêtres dans des processus indépendants. S'il plante, ton jeu continue à fonctionner, notamment si tu intègres le plugin "flashplayer" (mais qui voudrait de flashplayer dans un navigateur dans une fenêtre de jeu 3d ?).
Le code chronium à l'air plus simple, mieux conçu pour l'intégration. C'est le code GPL, libre de la version de chrome. Cependant il reste dedans quelques paramètres par défaut que je n'aime pas trop, orienté google, que l'on peut supprimer mais enfin.. Quand je dis mais enfin c'est que cette solution oblige à suivre l'un ou l'autre projet, les MAJ de sécurité sont faite avec les MAJ de fonctionnalité. Tu ne pourras pas garder une version d'aujourd'hui pendant 10 ans comme libwww. Donc si tu veux virer le code spécifique à google, il faudra le refaire à chaque MAJ.
Exemple : Chrome a fusionné la barre d'adresse et la barre de recherche. Cela parait anondin mais ce n'est pas du tout le cas. Quand tu vas dans le champ recherche de firefox, au fur et à mesure que tu saisis tes mots, ils sont transmis à google qui au passage va te faire des suggestions. Mais si tu fusionnes la barre d'adresse, celle où tu saisie l'url avec la barre de recherche, alors à chaque fois que tu entres une adresse sur le web, tu l'a transmet aussi à google, car comment faire la distinction entres mots de recherche ou URL ?
Du coup par ce mécanisme google trace tous tes déplacement sur le web, page par page, même en local sur un réseau privé ! Sans oublier tous les paramètres de connexion dans l'URL, comme
http://.../user=liria?sessionXXXX. Voila ce que j'appelle une option Chrome qui parait anodine mais relève du pure PRISM
Un traçage complet de tes activités sur internet à ton insu. Et la vraie question c'est dans le futur. C'est à dire une fois que tu t'engages, il est difficile de faire marche arrière, cela demande un investissement énorme en temps. Si demain certains aspects change dans le moteur, des aspects liés à google, qui fait que les désactiver rend le moteur inutilisable, que se passera-t-il ? eh bien les gens préféreront continuer avec chronium.
Ce n'est qu'un exemple, je ne peux pas te lister toutes les configs et trucs propres à google. Peut être que tout est désactivable, il nous faut des avis externes, je n'ai pas la compétence/connaissance suffisante pour donner un jugement définitif mais dans le fond c'est plus du feeling sur l'évolution de "l'histoire" et des choix technologiques depuis quelques années, que sur une analyse du code.
<Zatalyz> Le souci c'est d'être dépendant des choix d'une entreprise dont l'éthique n'est pas parfaite. le code est secondaire sur la question. Or, notre projet s'inscrit dans une éthique assez... heu bon disons qu'on est des drôles de capitalistes :p
Mais je crois que c'est là le point important. Si RC peut faire le choix de chromium, car leur intérêt pour le libre tient plus au pratique que d'une philosophie, de notre côté c'est un peu l'inverse. Si chromium est un choix intéressant, alors regardons les forks qui partent sur une philosophie de respect des données individuelles, il doit y en avoir. Qque ce soit une entreprise ou non est finalement secondaire, il faut bien à un moment faire confiance à un groupe de gens... et on ne peux jamais savoir comment ils évoluent. Je propose qu'on reste sur un choix qui suit la philosophie du libre et du respect des personnes
http://fr.wikipedia.org/wiki/Moteur_de_rendu_HTMLNote pour ceux comme moi qui se mélangent vite : webkit n'est pas lié à google et semble plus adapté dans ses fonctionnalités.
<YannK> Pour paraphraser Franck Lepage, notre cc, c'est pour devenir marxiste, et si tu l'es déjà, tu finiras trotskiste
<liria> bref l'approche google comme la pluspart des grands du web ce n'est plus de devenir le portail de référence mais plutôt de devenir le fournisseur d'identité de référence pour toutes ses autres activités [openid]. Finalement ce qui compte et se monétise ce sont les données/profils/habitudes/ des utilisateurs, du coup leur choix et technologies vont logiquement dans cette direction. La solution pour rendre captif l'utilisateur est de lui fournir un outil clef en main, facile à utiliser et c'est aussi le cas du programmeur qui peut intégrer la technologie simplement dans ses programmes. Comment aujourd'hui passer sur un site web sans derrière google analytique ou goole pub, ou ... ? D'où la raison qui fait que je ne suis pas pour la solution chronium malgré le fait qu'elle est super facile à utiliser comparé au reste. Bon pour résumer, on est d'accord sur le fait que nous ne choisissons pas une technologie dont les promoteurs suivent une démarche plutôt antinomique ? Du coup on revient à la base des projets libres, webkit & co ...
== Charte ===<liria> Zatalyz: il nous faut une charte, c'est très important. Notre choix vis à vis de chronium ne se justifie pas techniquement, c'est uniquement par rapport à nos choix "philosophique". Il nous faut donc une charte à la debian, une charte "libre" pour présenter le projet à RC, qui explicite chacun de nos choix.
Je pense à une charte plus orientée libre [que celle présentée ici :
viewtopic.php?f=4&t=227 ]. En fait cette charte apparaît dans le manifeste mais elle est noyé dans un discours autre. Ce que je veux dire c'est qu'il y a une différence entre utiliser du libre ou raisonner en terme de choix éthiques
Pour moi le libre se positionne dans un choix éthique pour le futur, qui peut être contraignant pour nous mais qui vise à une avenir meilleur. La plupart ne voient dans le libre que le coté "free" anglais, gratuit. Dans ce sens ma réticence vis à vis à chronium se justifie par des choix éthiques.
<YannK> tu veux définir un positionnement politique de khaganat ?
<liria> Oui absolument. Je pense que le manifeste a tracé une "politique" une "charte" mais de manière non explicite. Mes problème vis à vis de chronium je ne peux l'expliquer sur RC, techniquement on me dira que mon choix est idiot. Je ne peux que l'expliquer dans un cadre qui dépasse le simple code
<YannK> et alors, il n'est pas technique, mais éthique, ce choix, donc on peut s'en expliquer
<liria> voila, mais pour cela, il faut une charte qui l'explique clairement. Une charte se lit différemment, elle permet au lecteur de se poser, de réfléchir à ce qui est dit et de comprendre que c'est une philosophie qui dicte ces choix, qu'il soit pour ou contre. En discussion, on croirait voir des ados qui veulent refaire le monde. La différence c'est dans la continuité, le fait de poser jalon après jalon, ce qui apparaît via une charte. Ce qui n'est pas le cas en discussion live, c'est subtil.
Avoir un texte de référence auquel renvoyer peut aider, je lis le texte de référence, le fait de prendre le temps de lire, me met dans un autre état d'esprit. Ensuite je peux ne pas être d'accord mais je perçoit qu'il y a une réflexion au delà de la simple rêverie ou discussion de café, du coup je suis obligée de prêter attention à ce qu'ils disent, que je soit pour ou contre.
<YannK> Ta charte me plait bien car elle permet de se rendre compte de l'état d'esprit du projet, il faudrait y ajouter le côté politique/philosphique en un paragraphe, reste à réussir à formuler ça en quelques phrases simples
<liria> la charte dois avoir deux aspects :
-un coté points pratiques, ce qu'on permet ou pas
-et un coté philosophique qui explicite ces règles
Une lecture simple des règles permet de définir nos choix, il faut lire la suite pour comprendre plus mais ce n'est pas obligatoire.
*YannK aimerait bien un truc très sobre et simple, comme les lois de la robotique, qui permette pourtant la glose à l'infini.
<liria> oui c'est l'idée aussi de la liberté, savoir pour quoi on fait ou non ce choix et seulement si on veut lire le coté philosphique, se taper du blabla d'illuminé(e)s
