Le web libre, Tanguy Ortolo, Weboob et l'humanité ont besoin de vous, et je veux vraiment dire vous TOUS. L'article suivant a été écrit par moules<, président de la Weboob Fundation, homme de chaises et élu de Dieu.
Weboob a demontré que le navigateur n'était pas une fatalité. Nombreux sites ont été rendus utilisables, agréables, et accessibles (par exemple il est possible de lire les trolls énormes de DLFP sans avoir des blocs de commentaires qui font moins de 10 pixels de large).
Si des victoires ont été établies, la guerre est loin d'être terminée, et des ennemis redoutables se profilent.
Laissez-moi être très clair : ce n'est PAS hypothétique et je ne suis pas en train de parler de quelque chose qui pourrait arriver.
CECI NE DOIT PAS ARRIVER.
J'ACCUSE tout d'abord l'infameux Microsoft, même si il a enfin échoué du côté de l'utilisateur avec son navigateur Internet Explorer, il reste présent du côté serveur avec ASP.NET. Et il ne suffit pas de renommer Firefox en « Internet » pour l'éradiquer. Pourquoi est-ce tant un mal ? Car il combine un grand nombre de pratiques suboptimales.
J'ACCUSE ASP.NET (et d'autres Web Créateurs) de ne pas fournir de HTML lisible par un humain. Par là, je ne veux pas dire <div><div><div><div><div><span><br> TITRE </b><html>. Je veux dire <INPUT ID="ctl00$ContentPlaceHolder1$ctl00$ctl04$ctl00$btnImgConnexion.x">.
Même si l'on comprend l'amour de Microsoft pour les dollars, ce n'est pas raisonnable. Si cela continue, le Web pourrait ne pas s'en relever.
J'ACCUSE les Web Créateurs de sites inutilisables sans JavaScript d'alourdir leurs pages et la navigation sur celles-ci, de cacher les données à exploiter et de contribuer au réchauffement climatique (avec l'aimable participation de Firefox).
Il n'est pas normal de ne pas pouvoir soumettre un formulaire sans simuler ce que fait un code JavaScript illisible (car mal écrit ou « minifié »). Là encore, ASP.NET est un coupable chronique.
Heureusement Richard Stallman va nous libérer du JavaScript non-libre avec sa nouvelle initiative !
J'ACCUSE les Web Créateurs de sites usant de captchas d'empêcher un partage équitable (aucun rapport avec les poneys) de l'information via une mesure inefficace et pénible que ce soit pour l'utilisateur lambda que pour Weboob qui se trouve limité dans sa tâche d'automatiser les actions fastidieuses. Il s'agit d'une protection d'autant plus inutile que depuis plusieurs années, des boites douteuses permettent moyennant une modique rétribution de les résoudre à la chaîne (on se consolera en se disant que ça fait vivre une famille de petits chinois, quelque part dans le tiers monde).
J'ACCUSE les Web Créateurs de sites présentant une suite de balises sans identifiants et manquant cruellement de classe d'empêcher une localisation aisée des informations utiles présentes dans les pages, de nuire à l'accessibilité, de ne pas respecter la séparation entre les données et l'affichage.
J'ACCUSE les Web Créateurs qui ont décidé que leur site se comporterait différemment suivant l'User-Agent. Ou pas, ça permet parfois à Weboob de l'exploiter à son avantage.
Donc, merci d'exprimer votre opinion, aidez le Web à se faire boobiser, ircez, mailez et usenez que vous ne voulez pas voir ceci apparaître. Certains ont déjà commencé, après avoir participé à un des nombreux événements consacrés à Weboob. Si les décideurs pressés font le Web, ce sont les utilisateurs et les auteurs qui font le boob, et c'est le moment de le leur rappeler. VOTRE VOIX COMPTE.
Si vous êtes un journaliste, je suis immédiatement ouvert à… non je déconne, ce serait trop prétentieux !
Par contre, un Boobathon est organisé à la Fondation pour le Progrès de l'Homme le samedi 10 17 mars. Si vous aussi vous souhaitez contribuer à la libération du web, n'hésitez pas à vous manifester sur IRC (#weboob @ freenode) ou sur la mailing-list.
Enfin, si vous préférez picoler, sachez qu'en l'honneur de ses deux années d'existence, Weboob organise aujourd'hui une soirée au Petit Chat, 9 rue Saint-Denis à Paris, à partir de 19h. Les personnes intéressées sont priées de prévenir.
Merci à vous.
# Enfin un journal qui dénonce !
Posté par from_kobb . Évalué à 9.
Tout est dans le titre.
[^] # Re: Enfin un journal qui dénonce !
Posté par Astaoth . Évalué à 5.
Il ne "dénonce" pas, il "dénonce, grave" !
Emacs le fait depuis 30 ans.
# Booba(r)thon & Debian
Posté par theocrite (site web personnel) . Évalué à 9.
Petite précision, le boobathon ne se tiendra pas le 10 mars, comme initialement prévu (la FPH étant finalement indisponible à cette date), mais le 17 mars, c'est à dire le samedi d'après.
Sinon le boobarthon de ce soir sera également l'occasion de fêter l'arrivée de weboob dans sid.
[^] # Re: Booba(r)thon & Debian
Posté par hercule_savinien . Évalué à 3.
D'ailleurs si un gentil modérateur pouvait corriger, histoire d'éviter d'enduire les gens d'erreur, ce serait schwerte. :)
Le FN est un parti d'extrême droite
[^] # Re: Booba(r)thon & Debian
Posté par Lucas Bonnet . Évalué à 5.
Je veux bien, mais il me faudrait une preuve (confirmation de moules) ou un lien vers le site officiel qui annonce la bonne date, histoire de pas être victime d'un social engineering bas de gamme :)
[^] # Re: Booba(r)thon & Debian
Posté par Juke (site web personnel) . Évalué à 4.
https://symlink.me/projects/weboob/wiki/Boobathon-2012-03
[^] # Re: Booba(r)thon & Debian
Posté par Lucas Bonnet . Évalué à 3.
Fait.
# Icones des sites
Posté par Benjamin Verhaeghe (site web personnel) . Évalué à 2.
Sur le site de Weboob, les icones des modules officiels ou sites populaires sont pour la plupart modifiés. C'est par impossibilité légale de reprendre le logo je suppose?
Pourquoi vouloir utiliser une application différente pour chaque site (un peu comme sur les applications téléphone) plutôt que leur site internet (qui par ailleurs est parfois bien fait)?
En tous cas merci pour le boulot, notamment pour les sites bancaires où l'interface et la compatibilité avec grisbi, kmymoney et autres n'est pas toujours réussi. Cela me semble intéressant. (Pour l'instant je suis toujours a télécharger le relevé puis l'importer... pas compliqué mais cela devrait pouvoir se faire de manière automatique)
[^] # Re: Icones des sites
Posté par MrLapinot (site web personnel) . Évalué à 6.
On n’utilise pas une appli différente par site, on utilise la même appli pour des sites différents. Par exemple, mes comptes dans 3 banques distinctes sont consultables simultanément, avec une interface unifiée, et exportables en plein de formats dans boobank.
[^] # Re: Icones des sites
Posté par Juke (site web personnel) . Évalué à 6.
C'est justement le but de ne pas utiliser une application pour chaque site.
boobank pour tout les comptes banquaire
videoob pour les sites de videos etc...
[^] # Re: Icones des sites
Posté par laurentb (site web personnel) . Évalué à 6.
Oui. Le logo original n'est de toute façon souvent pas libre, donc difficile de l'inclure dans les sources. Et quitte à refaire le logo, autant s'amuser un peu (et le côté parodique permet de profiter d'une exception au droit d'auteur je suppose).
Cela changera peut-être dans le futur, puisque les modules sont maintenant capables de récupérer le « favicon », tout en nous évitant de le distribuer.
# Bonnes pratiques vs liberté
Posté par arnaudus . Évalué à 10.
Bon, je comrpends un peu le pourquoi du journal, mais je pense que tous les points de vue se défendent.
1) Les mauvais sites web sont souvent dus à l'incompétence des programmeurs. C'est comme le mauvais code. On a parfaitement le droit d'accuser les gens d'être mauvais, malheureusement, il n'y a pas vraiment de remède à l'incompétence.
2) Il y a un conflit d'intérêt évident entre les concepteurs des sites et les programmeurs de scripts. Dans la grande majorité des cas, l'objectif d'un site web est d'être visité et d'apparaitre sur l'écran de l'utilisateur exactement comme le concepteur du site l'a voulu, avec l'ergonomie qu'il a développé, avec les mentions qu'il considère comme importantes (y compris des trucs comme "contenu disponible sous CC-BY-SA"), avec la charte graphique, les logos, les marqueurs visuels qui ont couté très cher à mettre en place, et éventuellement avec la pub qui assure des revenus. Même si on peut ne pas être d'accord avec cette philosophie, il parait naturel que les concepteurs des sites n'aient aucun intérêt à faciliter le travail des outils destinés à trier le contenu, modifier la charte graphique, ou retirer les pubs. Il pourrait même sembler à certains qu'il pourrait même etre profitable de tout faire pour que ça ne soit pas possible.
3) Le HTML a une caractéristique particulière, c'est qu'il impose un modèle "open source" (je n'ai pas dit libre). Il existe tout plein de libristes qui admettent l'existence du logiciel proprivateur ; et dans cette optique, les méthodes d'obfuscation du HTML ne seraient qu'un moyen de mimer ce que pourrait être un site propriétaire : l'utilisateur ne dispose que d'une forme "binaire", le concepteur ne lui donne pas la possibilité d'étudier son fonctionnement ou de le modifier pour l'adapter à ses besoins.
4) Si les concepteurs de sites doivent quelque chose à leur visiteur, c'est l'efficacité de l'interface ou la continuité du service par exemple. Ce n'est pas du tout la stabilité et la "propreté" de la structure du site. Il est par exemple parfaitement admissible pour un webmaster, même pour un projet libre, de modifier la structure du site et l'arborescence des liens profonds. Ça casse des liens, c'est triste, mais la liberté de faire évoluer son site est fondamentale, on ne peut pas être prisonnier de ses visiteurs, et on a le droit de tout changer (de manière équivalente, on peut décider de ne pas assurer la compatibilité d'une nouvelle version d'un logiciel avec les anciennes, ce n'est pas immoral).
Au final, je comprends que les gens qui s'investissent dans weboob et dans d'autres projets similaires soient gonflés par tous ces problèmes et qu'ils préfèreraient que les concepteurs de sites pensent à eux, mais d'un autre côté, ils l'ont choisi : ils cherchent à utiliser un outil mis à leur disposition d'une manière qui n'était pas prévue (et peut-être même pas admise) par son concepteur. Je me vois mal aller dire à Wirlpool "j'ai démonté le capot du lave-vaisselle et j'ai mis ma teub dans le trou A8, mais il y a le rouage de la pale rotative qui passe devant, c'est vraiment un deisgn de merde et je ne peux pas utiliser l'appareil comme je le souhaite". Quand on veut jouer au plus malin, on doit l'assumer jusqu'au bout...
[^] # Re: Bonnes pratiques vs liberté
Posté par CrEv (site web personnel) . Évalué à 2.
Concernant le point 3.
Tu as des exemples de sites "obfuscés" ? Car en général je n'en vois pas. Je dirais même qu'il y a trois grandes catégories de sites :
Mais en fait je ne vois jamais de sites volontairement illisibles pour empêcher d'étudier le fonctionnement ou le modifier. D'ailleurs, étudier le fonctionnement de quoi ? (sachant que n'importe quel outil de dev, firebug et les pendants ie / chrome) sont capables d'afficher le html propre). Et aussi, modifier quoi pour ces propres besoins ?
[^] # Re: Bonnes pratiques vs liberté
Posté par arnaudus . Évalué à 6.
Le meilleur exemple que je connaisse c'est des noms d'images codés qui bougent tout le temps pour qu'adblock ne les trouve pas. Appeler tes pubs c342sdx.jpg , ça ressemble fort à de l'obfuscation.
Un autre exemple serait les interfaces 100% flash, même si je ne sais jamais si c'est volontaire ou simplement attribuable à la stupidité.
[^] # Re: Bonnes pratiques vs liberté
Posté par foutaises . Évalué à 3.
Attention à ne pas voir le mal partout quand même : a ce compte là on pourrait aussi dire que linuxfr fait dans l'obfuscation : on trouve très vite application-c4022eed62edce864ce4270e8ed909e9.css dans le code de cette page , selon toi est-ce aussi de l'obfuscation ?
[^] # Re: Bonnes pratiques vs liberté
Posté par goeb . Évalué à 1.
Tu as oublié tous ceux qui génèrent une partie du HTML par du javascript.
Exemple : www.google.fr. Ils n'ont pas de </body> ni de </html>. je ne sais pas si c'est généré par javascript, oublié, ou omis pour mise à jour périodique de la page...
[^] # Re: Bonnes pratiques vs liberté
Posté par Frank-N-Furter . Évalué à 2.
Exemple : www.google.fr. Ils n'ont pas de ni de . je ne sais pas si c'est généré par javascript, oublié, ou omis pour mise à jour périodique de la page...
C'est volontaire, et pas pour rendre le code obscure.
Depending on the time of day, the French go either way.
[^] # Re: Bonnes pratiques vs liberté
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 1.
C'est pour quoi alors ? ça m'intéresse j'avais jamais remarqué
[^] # Re: Bonnes pratiques vs liberté
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 1.
Ok j'ai cherché… sur google ;)
Donc, c'est normal c'est dans la norme html 4 il paraît et cela permet des économies de bande passante…
[^] # Re: Bonnes pratiques vs liberté
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Ahahaha. Ptite bite.
[^] # Re: Bonnes pratiques vs liberté
Posté par imr . Évalué à 2.
Ben non, il peut pas:
[^] # Re: Bonnes pratiques vs liberté
Posté par laurentb (site web personnel) . Évalué à 4.
C'est vrai, mais ce n'est pas une fatalité. Je serai prêt à payer un abonnement modique pour avoir accès à une bonne API. Cela devrait compenser par exemple les pertes de revenus liés à la publicité. De plus, fournir une information par une API coûte largement moins cher que de fournir un site complet.
Et je serai prêt à payer encore plus pour un module weboob maintenu par le site en question (et si les choses sont bien faites, le site pourrait ajouter un cache local permettant de diminuer le « coût » de weboob).
Je vois ce que tu veux dire. On a pu rencontrer du HTML bien pourri (notamment les sites de banques où il faut y aller de manière quasiment heuristique) et arriver à en faire quelque chose. Cependant le code JavaScript, surtout minifié, est une autre paire de manches.
Je n'ai rien contre leur liberté, mais je trouve justement étrange le peu d'attachement à la stabilité et la rétrocompatibilité des sites internet, alors que c'est beaucoup plus répandu dans le logiciel « lourd ». C'est d'ailleurs ce qui a poussé la création du système de mise à jour des modules dans Weboob. On est attachés à la stabilité des applications et de l'API (du moins dans une même version majeure), mais pour les modules on est obligés de s'aligner sur les sites.
[^] # Re: Bonnes pratiques vs liberté
Posté par arnaudus . Évalué à 3.
La rétrocompatibilité des liens peut en effet poser problème (c'est même certainement assez pénalisant pour le référencement), mais il faut bien avouer que personne se s'attend à avoir un internet pérenne. Même dans le libre ; prends par exemple tous les rapports de bugs avec une capture d'écran hébergée chez un truc gratuit qui supprime les fichiers au bout de 30 jours, les liens cassés vers les tutoriels sur comment installer StarOffice sur Mandrake... Le web ne peut pas vivre figé, on peut le regretter ou non, mais l'usage veut qu'un lien cassé soit quelque chose d'acceptable.
Pour les changements d'API, c'est en théorie complètement transparent pour l'utilisateur "normal" ; si tu passes par Weboob, c'est une autre affaire, mais ce n'est pas une utilisation "normale".
[^] # Re: Bonnes pratiques vs liberté
Posté par hercule_savinien . Évalué à 3.
Un coup sec derrière la nuque ?
Dans le cas d'une banque en ligne ou d'un service (pseudo) public, c'est inacceptable.
Dans le cas des logiciels libres (mediawiki, redmine, linuxfr, etc.), il n'y a pas de volonté manifeste (normalement) d'éviter ce genre de comportement.
Les autres sites, à la limite, on pourrait comprendre dans certains cas.
Est ce que tu penses que les webmasters avaient prévu adblock, noscript et autres ? Penses-tu qu'adblock soit une mauvaise chose ?
Le FN est un parti d'extrême droite
[^] # Re: Bonnes pratiques vs liberté
Posté par arnaudus . Évalué à 3.
Bien sûr que non, mais je ne trouve pas anormal que certains sites tentent de gêner le fonctionnement d'Adblock. C'est un petit jeu pas très productif, mais c'est la vocation de tels systèmes de jouer au chat et à la souris.
# Captcha
Posté par Frank-N-Furter . Évalué à 5.
http://captchatrader.com/ or https://bitbucket.org/spoob/pyload/src/7dcc22c4b634/module/plugins/captcha/captcha.py
Depending on the time of day, the French go either way.
[^] # Re: Captcha
Posté par imr . Évalué à 3.
Ce qui serait super ironique et amer, ce serait que captchatrader.com soit en fait une boite appartenant à une major d'holywood.
# captchas
Posté par Gof (site web personnel) . Évalué à 3.
Weboob peux juste montrer les captchas à l'écran et demander à l'utilisateur de le « résoudre ».
Il pourrait aussi s'interfacer avec une librairie tel que http://caca.zoy.org/wiki/PWNtcha ou http://www.brains-n-brawn.com/default.aspx?vDir=aicaptcha (ou autre)
[^] # Re: captchas
Posté par moules . Évalué à 3. Dernière modification le 16 février 2012 à 12:04.
Il y a justement un système de callbacks qui permettent aux modules de faire des prompts à l'utilisateur (en cli ou graphiquement, suivant la nature de l'application). Les modules n'ont pas encore été confronté à des sites présentant des captcha (ou alors les résout tout seul, comme pour adopteunmec), donc ce mécanisme n'est pas encore utilisé.
Mais demander à l'utilisateur de résoudre la captcha empêche l'automatisation des tâches.
Pour ce qui est de PWNtcha, il ne supporte qu'un set réduit de captchas, dans lequel n'est pas inclus recaptcha qui est quand même le plus utilisé.
[^] # Re: captchas
Posté par arnaudus . Évalué à 3.
J'ai loupé un épisode ou c'est plus ou moins exactement l'objectif?
[^] # Re: captchas
Posté par CrEv (site web personnel) . Évalué à 3.
le captcha n'est pas là pour éviter l'automatisation des tâches, il est là pour éviter les bots de spam / virus.
L'automatisation en soit ne pose pas de problème (genre aller récupérer ses comptes tout seul comme un grand).
En tout cas c'est comme ça que, historiquement, je note l'arrivée des captcha (par exemple verrouillage des commentaires de blogs)
[^] # Re: captchas
Posté par arnaudus . Évalué à 4.
Eh bien va voir sur Wikipédia par exemple :
Le captcha n'a qu'un seul but : s'assurer qu'il y a une personne physique derrière l'écran. De mon point de vue, c'est exactement synonyme à "empêcher l'automatisation d'une tâche".
Éviter le spam dans les commentaires des forums par exemple, c'est une application du captcha. Il y en a beaucoup d'autres : limiter le nombre de fichiers téléchargés sur
megauploadrapidshare, par exemple.Donc, ce que tu critiques, c'est une utilisation injustifiée du captcha : on bloque l'automatisation d'une tâche que tu souhaiterais automatiser.
On pourrait trouver plein de justifications possibles : gêner une éventuelle tentative de deviner le mot de passe, ou simplement empêcher une utilisation par API qui est vendue aux professionnels.
[^] # Re: captchas
Posté par hercule_savinien . Évalué à 4.
Tu confonds but et moyen.
99.99% des gens mettent des captchas pour éviter le spam.
Le reste, je doute qu'il y aient réfléchi outre mesure.
Le FN est un parti d'extrême droite
[^] # Re: captchas
Posté par CrEv (site web personnel) . Évalué à 3.
Ben non, justement, c'est pas du tout synonyme.
Si je suis physiquement derrière mon écran mais que je lance un script qui me connecte sur le site de ma banque, récupère mon solde et l'affiche dans conky, il s'agit bien de l'automatisation d'une tâche. Pourtant il y a quelqu'un physiquement derrière l'écran.
Par contre la définition wikipédia est bien meilleurs, car ce n'est pas du tout le fait qu'il y ait quelqu'un ou non derrière l'écran, il s'agit de savoir qui exécute les actions. En ce sens oui ça permet d'interdire les automates. Mais ce n'est pas pour autant, de mon point de vue, l'objectif. L'objectif réel étant d'interdire le spam. La sélection automate / humain n'étant finalement qu'un moyen technique d'y parvenir, même si on met rajoute des faux positifs (interdiction d'automates non néfastes ou interdiction à des personnes n'arrivant pas à décripter les captcha) et des vrai négatifs (je sais pas si ça ce dit) (autorisation d'automates capables de lire les captcha).
[^] # Re: captchas
Posté par vermillon . Évalué à 1.
C'est un faux négatif. Un vrai négatif, ce serait de correctement laisser se connecter un humain.
[^] # Re: captchas
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 16 février 2012 à 12:05.
Weboob marchant en ligne de commande / scripts, ça va pas être facile quand même.
Et si c'est pour les résoudre automatiquement, autant les supprimer définitivement alors !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: captchas
Posté par zebra3 . Évalué à 5.
Si c'est du jpeg, tu peux le convertir en ascii-art avec jp2a. Après, ça devient un peu sportif mais ça reste possible :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: captchas
Posté par gUI (Mastodon) . Évalué à 2.
Oui ou libcaca doit faire ça aussi non ? Sauf si c'est que pour les videos ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: captchas
Posté par Jux (site web personnel) . Évalué à 4.
Déjà que la moitié des captchas sont difficilement lisibles dans leur forme original, j'imagine pas ce que ça donne en ASCII :-D
[^] # Re: captchas
Posté par lendemain . Évalué à 7.
excuser moi, je vais de ce pas déposé un brevet: la captcha en ascii art.
[^] # Re: captchas
Posté par Grégory Landais (site web personnel) . Évalué à 3. Dernière modification le 16 février 2012 à 14:46.
w3m (avec le paquet w3m-img sous debian) parviens à afficher une image dans un terminal. Exemple :
[^] # Re: captchas
Posté par Anonyme . Évalué à 2.
fbi (fbida sous Arch Linux) affiche aussi les images en TTY.
[^] # Re: captchas
Posté par Smarter . Évalué à 1.
C'est quoi le truc? J'ai installé w3m-img et lancé w3m dans Konsole, mais toujours pas d'images.
[^] # Re: captchas
Posté par gnuzer (site web personnel) . Évalué à 2.
Je pense que ça dépend du terminal. Chez moi, en TTY, ça marche bien. Dans xterm, uxterm, et lxterm (et je suppose tous les autres *xterm), les images s'affichent bien également. Dans terminator et gnome-terminal les images s'affichent presque bien. Dans lxterminal et xfce4-terminal, les images ne s'affichent pas. ('pas essayé konsole par contre)
# plus direct
Posté par lendemain . Évalué à 6. Dernière modification le 16 février 2012 à 12:24.
Au lieux d'accuser les développeur web d'éssayer de faire des sites utilisables sur les différent navigateurs web.
Accuse les de ne pas fournir d'api rest/web-service/boob-service/non-http standardisé, libre et bien documenté.
C'est plus mieux non?
n'hésitez pas à me moinser(attention c'est de la psychologie inversé) si de telles choses existes.
[^] # Re: plus direct
Posté par Grunt . Évalué à 7.
Voire, de ne pas proposer le même service via un autre protocole. Typiquement, un moteur de forum (style phpBB) pourrait très bien avoir un backend NNTP, pour ceux qui préfèrent. Ou bien un plan de réseau de transport pourrait être disponible dans sous formes de fichiers vectoriels avec rsync (afin de ne télécharger que les différences en cas de modifications).
Ça existe déjà pour certains cas : recevoir un mail en cas de réponse à un sujet de discussion, rejoindre un salon IRC soit via une appli Web soit avec un client IRC, la compatibilité du chat Facebook© avec les clients XMPP..
Ce serait bon de généraliser ce type de "ponts" afin que le Web, et HTTP, ne soient plus un chemin imposé, si le service est naturellement convertible, côté serveur, dans un protocole bien adapté.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: plus direct
Posté par barmic . Évalué à 1.
Entre les forums web et nntp la différence d'un point de vu fonctionnel est énorme. Ce n'est pas parce que les deux sont des forums qu'ils ont les mêmes fonctionnalités.
Par exemple, je ne crois pas que tu puisse avec nntp, fusionner/scinder des fils, en marquer comme résolu (ajouter [résolu] comme le font certains forum n'est pas très agréable et complexifie la classification). Je ne crois pas non plus que tu puisse faire de l'édition après envoie.
Mais oui ce serait bien que nntp évolue pour pouvoir faire plus de choses.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: plus direct
Posté par Grunt . Évalué à 1.
Oui, je suis d'accord. D'un autre côté, vu qu'à 95% l'usage est le même (rechercher - lire - répondre - citer), c'est idiot de gaspiller autant de ressources en MySQL - PHP - Apache - javascript - navigateur Web juste pour les 5% restants. Pas tant d'un point de vue économique ou écologique que dans une optique d'a-centralisation d'Internet (avec une ligne ADSL et un modem-routeur en ARM je peux faire tourner un node NNTP, pas un forum phpBB).
Ce qui fait que je suis d'accord avec la solution que tu proposes :
Pour que les anciens protocoles évoluent il faudrait aussi un peu plus d'utilisation.. pour l'instant, la seule chose qui évolue activement sur Internet ce sont les couches de base (IP de v4 vers v6, des ajouts de sécurité sur DNS, BGP).. et le format "HTML" avec tout son contenu (vidéo, images, scripts). C'est triste.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # XMPP
Posté par BFG . Évalué à 4.
On constate tout de même des évolutions, par exemple XMPP, qui s'est fait une place tout seul, et évolue grâce aux XEP.
Il est aussi intéressant de voir qu'XMPP a donné lieu à d'autres protocoles par son extensibilité et sa qualité.
Cependant, ces protocoles dérivés restent des protocoles dédiés à un programme, et non à une tâche. Salut à Toi et Jappix sont deux protocoles dérivés d'XMPP, mais ils ne sont (à ma connaissance extrêmement limitée) compatibles entre eux du point de vue des fonctionnalités relatives au réseau social. Peut-être un jour verra-t-on une une plus grande standardisation entre ces deux (ce n'est qu'un exemple).
XMPP commence à servir de socle à de nouveaux protocoles, peut-être semble-t-il avoir une certaine flexibilité, comme HTTP et HTML/etc. en a une, qui a conduit à ce qu'il soit utilisé pour tout et n'importe quoi, même quand c'est sous-optimal. Certains se décarcassent à faire évoluer HTTP et HTML en ajoutant SPDY/WebSockets, la vidéo, WebGL, le stockage hors-ligne, la géolocalisation, etc. mais c'est signe qu'on manque d'un certain nombre de protocoles plus adaptés, et surcharger HTTP/HTML uniquement pour cette raison est une erreur.
Si XMPP commence vraiment à prendre plus d'ampleur, c'est bien, mais il ne faudrait pas faire la même erreur que la sur-utilisation d'HTTP.
[^] # Re: XMPP
Posté par zebra3 . Évalué à 1.
Par curiosité : où donc ? Parce qu'à part Gtalk (que je ne vois utilisé nulle part…), je ne vois pas où il a pu se faire une place.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: XMPP
Posté par barmic . Évalué à 2.
Ça ne se voit pas mais il est utilisé par facebook aussi (pour le chat et en interne).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: XMPP
Posté par BFG . Évalué à 2. Dernière modification le 17 février 2012 à 12:56.
Ainsi que la messagerie Microsoft, et celle d'Apple. Je pense qu'il ne veut pas le(s) compter car il n'y a pas la fédération. Facebook et le reste du monde ne sont pas dans la même composante connexe bien qu'ils utilisent tous les deux XMPP.
[^] # Re: XMPP
Posté par barmic . Évalué à 2.
Ce n'est pas une preuve que XMPP est de plus en plus utilisé ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: XMPP
Posté par BFG . Évalué à 4.
Si, mais cela diminue profondément son intérêt.
C'est un peu comme si chaque fournisseur d'email ne permettait de communiquer qu'avec les autres utilisateurs de ce même fournisseur. C'est trop local. Le fait que ça utilise XMPP n'est qu'un "détail d'implémentation". Ils auraient aussi bien pu inventer leur propre protocole et en publier les spécifications que ça n'aurait fait presque aucune différence.
[^] # Re: XMPP
Posté par barmic . Évalué à 2.
L'objectif était de montrer la stature que prend ce protocole notamment grâce à sa flexibilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: XMPP
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Alors petite précision à ce sujet. On est, et on cherche à être compatibles entre nous au sujet de nouvelles fonctionnalités (celle qui me vient principalement en tête est le microblogage); et pour ce on s'appuie sur des XEP qui sont en cour d'élaboration, et qui ne sont donc pas encore des standards (Celle ci pour ceux que ça intéresse). La standardisation et donc la compatibilité entre client est un point important que nous ne voulons pas perdre.
Cependant, les fonctionnalités étant nouvelles, il y a aussi des expérimentation. Buddy Cloud par exemple élabore son propre protocole pour le microblogage. Je les ai rencontré au FOSDEM, ils envisagent la standardisation, mais à terme, le but est de tester avant dans leur coin, et de le proposer si c'est valable.
À ceci s'ajoutent les fonctionnalités qui ne sont pas standards. Salut à Toi par exemple propose la gestion des droits par groupes (ce que Google appelle les cercles, même si ça existait dans SàT avant que G+ ne soit publique). Étant à ma connaissance le seul projet basé sur XMPP à permettre ça (sinon Diaspora permet quelque chose de similaire que eux appellent aspects), ce n'est pas encore un standard. Mais je pense que ça la deviendra à terme. Pour le moment ça utilise une méthode bricolée qui ne fonctionne qu'avec Openfire, il est prévu de revoir ça très rapidement (c'est d'ailleurs ma prochaine chose dans ma TODO) pour que ça fonctionne de manière plus générique.
Donc pour résumer, oui on est standard et on ne fait pas de « sous protocole propriétaire »: le microblogage Jappix (ou MOVIM), est compatible avec celui de SàT.
Par contre il y a des différence sur les terrains expérimentaux, parce que justement c'est expérimental. Mais le but est pour la plupart des projet de standardiser les nouveauté. Seulement le processus de standardisation est long, et changer un protocole a des conséquences, c'est pour ça qu'il peut y avoir des différence entre un projet qui implémente une nouveauté, et la version standard (l'exemple le plus connu est celui de Jingle version Google qui diffère du Jingle standardisé: Google passe à la version standard, mais ça ne se fait pas en un claquement de doigts).
[^] # Re: XMPP
Posté par BFG . Évalué à 2. Dernière modification le 17 février 2012 à 13:02.
Mes excuses, je ne savais pas (faute d'intéressement et d'utilisation), c'était donc un mauvais exemple. J'aurais pu parler des différentes solutions de surveillance de serveurs basées sur XMPP, mais hélas, je n'en sais pas plus non plus, peut-être qu'également il y a concertation entre celles-ci pour que des standards de supervisions basés sur XMPP émergent.
[^] # Re: plus direct
Posté par barmic . Évalué à 1.
Les serveurs nntp n'utilisent pas de base de données ? Si c'est le cas c'est probablement qu'ils ont peut d'utilisateurs …
C'est un cercle vicieux, mais à la base je crois savoir que nntp était très utilisé (il y a 15 ou 20 ans). Peut être que c'est à l'IETF de se remettre en cause plutôt qu'aux utilisateurs.
L'énorme avantage du web, le truc qui fait que ça a tout écrasé c'est les moteurs de recherche. Si linuxfr était un serveur nntp comment ferais-tu pour savoir qu'il existe ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: plus direct
Posté par Juke (site web personnel) . Évalué à 3.
Ça ne semblait pas si obscur à l'époque, ceci dis je ne sais plus comment j'était tombé dessus, en parcourant la hierarchie peut être.
https://linuxfr.org/users/juke/journaux/acces-nntp-linuxfr
[^] # Re: plus direct
Posté par barmic . Évalué à 2.
Parcourir une arborescence pour rechercher des forum intéressant c'est pas super agréable et le problème d'une arborescence c'est que c'est centralisé et que pleins de forum pourraient aller dans plusieurs branches.
Il faudra de toute manière publier les messages sur le web pour gagner en visibilité et que des nouveaux puissent faire des recherches sur le forum sans inscription et sans télécharger l'ensemble des messages.
Comment ça se passe avec nntp ? Les messages restent sur le serveur ou ils sont téléchargés ? S'ils sont téléchargés, avec un forum double-pile web/nntp ne me semble pas possible sans brider de manière importante la partie web (impossible de retoucher/déplacer un message après envoie).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: plus direct
Posté par Juke (site web personnel) . Évalué à 3.
Passer par son navigateur non plus car ça ne permet pas de bénéficier d'un bon correcteur orthographique.
C'est pourtant ce que propose linuxfr sur les forums.
L'arborescence en elle même est centralisée, mais usenet ne l'est pas.
Je vois pas de contre indications à être dans plusieures branches.
C'est intéressant de publier sur plusieures plateforme, ou de faire une client web effectivement, comme il peut être intéressant pour certaines personnes de consulter leurs mails via le web.
Les mêmes « problemes » se posent via le web, comment retouche/déplace (RAIVI-SIONISTE !!! ) un message après envoi alors que le lecteur l'a téléchargé ?
[^] # Re: plus direct
Posté par Trollgouin . Évalué à 1.
Si mes souvenirs sont bons, j'utilisais des recherches sur la hiérarchie et nom un parcours à la main (les noms étaient suffisamment explicites), pour ensuite souscrire aux sujets qui m'intéressaient. Je trouve qu'un des avantages était que l'info était moins dispersée (sans doute parce que moins nombreuse aussi).
[^] # Re: plus direct
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
En général non.
Soit ça utilise directement le système de fichier :
fr.usenet.diversdevient$NEWS/fr/usenet/divers/, chaque post étant un fichier dont le nom peut être du genre MD5(MId), avec éventuellement des fichiers d'index.Soit c'est une sorte de système de fichier placé dans un gros fichier-blob, optimisé spécialement pour un spool Usenet. Ce qui se rapproche un peu d'un bon vieil ISAM des années 80 ;)
Plus de détails (pour INN) ici ou là.
[^] # Re: plus direct
Posté par Moonz . Évalué à 2.
Un node NNTP connecté avec personne, oui, c’est possible, mais ça a pas grand intérêt.
Par contre, si tu veux faire du peering avec un node usenet, m’est avis qu’en tant que particulier tu n’en auras jamais les moyens.
[^] # Re: plus direct
Posté par gUI (Mastodon) . Évalué à 7.
J'ai rien compris à ta "psychologie inversée", alors dans le doute, j'ai moinsé.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: plus direct
Posté par Frank-N-Furter . Évalué à 8.
Dans le doute, toujours moinser.
Depending on the time of day, the French go either way.
[^] # Re: plus direct
Posté par CrEv (site web personnel) . Évalué à 1.
Ok, c'est fait !
(tu parlais de ton commentaire, non ? ;-) )
[^] # Re: plus direct
Posté par niconoe . Évalué à 3.
J'ai faillu te plusser, puis j'ai comme été saisi d'un doute.
[^] # Re: plus direct
Posté par Jeremy Monnet . Évalué à 2.
Je te moinsse par principe; je vais m'expliquer.
Dans ce cas particulier, je suis le dev qui s'est coltiné ce site, et j'ai contacté l'éditeur pour lui annoncer mes intentions, et lui demander si il existait une interface web-service ou autre pour automatiser la chose. Je n'ai pas eu de réponse. En même temps, ce ne serait pas la première fois qu'un formulaire de contact ne fonctionne pas…
Ensuite, sur les aspects techniques, avoir 3 balises DOCTYPE et 4 balises html dans une même page, c'est sale. Avoir un flux rss référencé dans la page qui ne fonctionne pas (erreur serveur) c'est mal. Quoi qu'on en dise. N'avoir qu'un seul formulaire pour l'ensemble des actions, ça va à l'encontre de tout, et surtout de la simplicité, même pour les devs eux-mêmes.
Et l'incompétence, je suis d'accord avec celui qui commente en disant "un coup sec derrière la nuque". J'en ai marre de me taper des gros nuls ("des experts") au bureau tous les jours.
# Norme ?
Posté par Anthony Jaguenaud . Évalué à 2.
Il me semblait que la norme imposait que le site soit lisible pour les mals-voyants. Si c’était effectivement le cas, votre boulo serait plus simple… j’ai déjà envoyé des mails
d’insultede mécontentement à des web master.Le problème est que certain sans foute royalement. D’autre ne sont pas joignable, d’autre ne réponde pas :-(
[^] # Re: Norme ?
Posté par muchos (site web personnel) . Évalué à 3.
Non. Des conditions d'accessibilité (pas seulement la gestion du handicap visuel) sont exigées des sites institutionnels, mais pas souvent respectées.
Pour tout dire, bien coder n'est même pas une norme. Alors l'accessibilité… :/
Ah, mais c'est has-been les formulaires de contact ! Faut touiter maintenant !
Debug the Web together.
[^] # Re: Norme ?
Posté par Anthony Jaguenaud . Évalué à 2.
Pour le contact, je pensais à l’adresse : webmaster@domaine.fr qui généralement revient en : compte inexistant.
[^] # Re: Norme ?
Posté par Reihar . Évalué à -6.
Quid de contact@domaine.tld ?
# Le 17 mars ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -1.
Sérieux ?
[^] # Re: Le 17 mars ?
Posté par patrick_g (site web personnel) . Évalué à 3.
C'est pour ma fête !
# ils ne veulent PAS
Posté par steph1978 . Évalué à 5.
Tout d'abord bravo pour ce projet.
Fournir une architecture un peu élégante à tous les scripts que nous avons pu faire dans notre coin pour améliorer notre expérience avec le web est une très belle initiative.
Mais justement, on parle bien de hacks.
Les sociétés qui mettent en place des sites web grand public (souvent gratuits) ne le font pas pour que nous puissions facilement en contourner l'usage premier.
Si ils avaient voulu faire des systèmes ouverts, ils auraient proposé des webservices, comme ils le font avec leurs partenaires ou leur clients pro, moyennant finance d'ailleurs.
Une banque veut que l'utilisateur voit ses offres d'assurance vie quand il consulte ses comptes.
Un site de partage de vidéo veut que le visiteur voit les vidéos suggérées et les pubs qu'il affiche en même temps que la vidéo.
Rien que adblock est difficilement acceptable pour les sites qui vivent de la pub; c'est un peu comme si on inventait des lunettes qui filtrent les affiches 4x3.
Car comme le dit Homer S: "If you don't watch [commercials] it's like stealing TV".
Je pense donc qu'il sera toujours aussi laborieux, bien que toujours possible, de développer des hacks de site web.
Mais, longue vie aux boobs !
[^] # Vivre de la pub
Posté par Reihar . Évalué à 0.
Mauvais modèle économique : changer de modèle économique.
[^] # Re: ils ne veulent PAS
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Ne jamais attribuer à la malignité ce qui dépend de l'incompétence.
[^] # Re: ils ne veulent PAS
Posté par steph1978 . Évalué à 5.
De manière générale, je plussois. C'est ma devise, en particulier pour lutter contre les théories du complot.
Maintenant, dans ce cas précis, pour avoir travailler sur les systèmes d'informations de grand comptes, je t'assure que les compétences sont présentes et que quand il faut faire des outils interopérables, ils savent faire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.