Apres, si tu veux m'expliquer comment faire un truc comme GMail ou de l'ajax sans code qui tourne cote client, ben tu me fais signe.
Je n'ai jamais dit que le code côté client c'était mal. Je dis qu'un truc comme Gmail ça s'appelle par exemple Thunderbird. Avec du code choisi par l'utilisateur (il peut remplacer Thunderbird par Kmail ou Evolution) indépendamment du service (t'as déjà utilisé le webmail de Yahoo chez Google ou l'inverse ? Ah zut on peut pas). Avec une économie de ressource incroyable à fonctionnalités égales. Avec de bien plus grandes facilités pour héberger soi-même le service (même si le code source de Gmail était libre, je préfère mille fois mieux me taper l'installation d'un postfix+dovecot côté serveur et Thunderbird côté client, que l'installation d'un Gmail-like sur un LAMP).
Ben ça change pas grand chose au pb, tu veux toujours valider tes données cote client avant envoi, parce que t'as pas forcement envie de te fader le reremplissage du formulaire cote serveur et que tu veux avertir l'utilisateur des pb avant meme qu'il clique sur envoyer.
D'un autre côté, si tu laisses l'utilisateur choisir son application cliente au lieu d'en proposer une toute faite en javascript, je suis absolument certain qu'elle finira par proposer de garder en mémoire les données saisies au lieu de les retaper. Exemple, 100% des clients de messagerie instantanée, en cas de mot de passe erroné ou de données rejetées par le serveur, gardent dans les champs déjà remplis les données saisies. Par contre, des sites Web qui te bennent tout, ou qui déclarent comme invalide un truc qui est valide, j'en ai vu ma dose.
Si c'est pour coder des applications aussi merdiques et les imposer à l'utilisateur final, il vaut franchement mieux le laisser choisir une application qui fonctionne, qui tourne chez lui.
A peu près aussi con que réinventer un protocole dédie pour poster 140 characteres sur une ressource.
Pas la peine, il existe : XMPP. Et il est à tous points de vue de meilleure qualité que le bordel mis en branle par l'interface de Twitter. Que ce soit "le site Web Twitter dans un navigateur" ou bien "l'API Twitter pour faire sa propre application over HTTP".
Maintenant, si t'as une meilleur idée que HTTP pour transférer des données sans authentification, je suis toute ouïe.
C'est pas forcément une "meilleure idée", ce sont des idées équivalentes : FTP, rsync, NFS, BitTorrent. Des protocoles standards qui permettent de copier des données publiées, et qui peuvent offrir des fonctionnalités supplémentaires par rapport à HTTP. rsync est réellement fait pour ne copier que ce qui a changé. BitTorrent permet de répartir la charge entre tous les gens ayant déjà téléchargé le fichier.
Maintenant, je veux bien que tu m'expliques en quoi HTTP live streaming est plus complexe et gourmand en ressource que bittorrent pour une video embarquée dans une page web. Et au passage, tu vas m'expliquer comment tu garantis de recevoir la video en premier avec bittorrent, vu que le concept c'est justement "chope ce qui est dispo, dans n'importe quel ordre, on s'en fout end' façons, c'est pour visionner offline".
BitTorrent, en l'état, n'est pas utilisable pour cet usage, on est d'accord. Mais il ne lui manque pas grand chose. HTTP non plus n'a pas été prêt pour le streaming tout de suite (sans les requêtes "Partial Content" qui permettent de récupérer la vidéo à partir d'un certain délai, ça serait franchement moins pratique. Je pense que tu vois mieux que moi de quoi je parle sur ce point :D)
Et au passage, tu vas m'expliquer comment tu garantis de recevoir la video en premier avec bittorrent, vu que le concept c'est justement "chope ce qui est dispo, dans n'importe quel ordre, on s'en fout end' façons, c'est pour visionner offline".
Je sais tres bien ce que tu vas me répondre a ce point c'est "la video, tu la mattes offline". En gros, dit moi ce dont t'as besoin, je t'expliquerais comment t'en passer.
Tu connais l'histoire des abonnés Free chez qui Youtube il rame tellement qu'ils ouvrent la page, et patientent dix minutes pour regarder une vidéo de deux minutes ? Je trouve qu'ils ressemblent furieusement à des gens qui ont appris à se passer du caractère instantané du streaming. Ils ont besoin de streaming, la réalité physique du réseau (des tuyaux congestionnés, tout simplement) leur apprend à s'en passer.
Si c'était possible de "lire du BitTorrent en streaming" je suis certain qu'avec une dizaine de seeders (autrement dit, une dizaine de gens ont vu la vidéo récemment) ça irait plus vite s'ils cliquaient sur le lien "torrent-streaming" que sur le lien "Youtube".
Tu peux utiliser RTSP, mais va falloir m'expliquer quel est l'intérêt de RTSP quand 95% des clients peuvent telecharger la video en moins de qq secondes via un protocole achement plus simple, et faire le playback de leur cote.
Je t'explique ça avec plaisir. Le RTSP, je peux le lire dans VLC, ou dans mplayer si VLC me plaît pas/plante chez moi/n'est pas dispo sur mon OS. Je peux l'enregistrer. Je peux le mettre sur pause avec le raccourci que je connais par coeur de mon "lecteur qui lit toutes mes vidéos". Je peux le minimiser et continuer à lire le texte de la page Web en n'écoutant que le son, parce que l'image c'est juste quelqu'un qui parle et ça distrait plus qu'autre chose. Ouais, c'est une bonne idée en fait, au lieu d'incruster dans une page Web une application Flash (ou sa version moderne, une balise < video >, qui contraint à utiliser le lecteur intégré au navigateur), un lien "rtsp://" c'est mieux. Bien mieux à tous points de vue. Ça fait moins "fancy kikoolol 2.0", mais c'est carrément plus pratique. Genre, je vois l'article, je peux décider de commencer à télécharger la vidéo, lire tout l'article, puis lire la vidéo, si ma connexion est pas terrible. Avec du YouMotion incrusté ça demande des manipulations rusées, différentes selon chaque site, à base de "je lance la lecture, je baisse le son, je mets sur pause, je vérifie que la barre de chargement, si y'en a une, est pleine, je remets au début, je remonte le son, je relance la lecture".
Super, et next thing you know, tu te retrouves aver 150 protocols differents.
grep -v ^# /etc/services | wc -l
556
C'est grave docteur ? La terre va arrêter de tourner ?
On peut lire une ressource, la créer, la modifier, la supprimer. Tu couvres 99,9% des besoins avec ça, sur un protocole tellement simple a comprendre que meme toi t'arrives (presque) a le comprendre. Protocole qui est implemente par quasiment tout le monde partout (forcement, simple comme il est...)
Ça c'est le beau protocole bisounours, et je suis d'accord avec toi sur ce point. Mon problème, c'est que, de facto, le protocole tu l'utilises dans 99,9% des cas avec l'application choisie par le fournisseur du service. Et cette application se présente sous la forme d'une URL HTTP qui ouvre une page dans laquelle se "passent des choses" qui sont, toutes ou presque, hors de contrôle de l'utilisateur lambda.
Maintenant, je vais te dire comment ça aurait pu, ou ça peut tourner, ce genre d'histoires. En prenant l'exemple des XEP (extensions au protocole XMPP). T'as un protocole de base (XMPP), on se rend compte qu'il permet de faire pas mal de choses, on regroupe des usages similaires dans des XEP histoire de pas éparpiller les implémentations. Un mélange de souplesse et d'intéropérabilité.
Sur le Web, le même schéma pourrait être appliqué. Combien de sites d'information se présentent sous l'aspect "article - ressources externes (vidéos, liens..) - commentaires" ? Des centaines, voire des milliers. Actuellement ce sont des milliers d'applications Web qui font toute la même chose (d'un point de vue fonctionnalités). Proposer (comme j'ai tendance à le faire) de remplacer ce bordel par des serveurs NNTP en réservant le droit d'initier un fil de discussion à ceux qui gèrent le serveur de news, c'est peut-être un peu exagéré. Mais on pourrait imaginer une vraie standardisation du modèle HTTP actuel, qui aboutirait à ce que l'utilisateur final ait un client dédié à la "lecture de journaux", qui saurait où taper pour avoir l'article, pour avoir la/les vidéos, pour lire/publier les commentaires. Autrement dit, chaque utilisateur choisit parmi plusieurs applications et garde la même sur chaque site. Au lieu d'avoir, comme actuellement, une application liée à un site. C'est pas sympa et ergonomique, comme idée ?
Et si iChat se met a afficher un flic pour les certifs auto signes, Jabber va devenir un mauvais protocole aussi?
Je parle (même si ça n'en a pas l'air) du point de vue de l'utilisation finale, tant pour celui qui consulte l'information que pour celui qui va la diffuser et/ou l'héberger. Et je montre du doigt plusieurs obstacles à une "libération d'Internet", ou "libération du Web" si tu veux. Les messages flippant des navigateurs sont un de ces obstacles, qui n'est pas présent sur d'autres clients destinés à d'autres protocoles (où on mentionne simplement la non validité du certificat, où on accepte d'associer un certificat auto-signé à un serveur particulier, sans faire déborder cette acceptation sur tous les serveurs, et en prévenant si le certificat change).
Et, pour résumer, je dirais que le Web, dans sa forme actuelle, implique nécessairement, pour celui qui publie, qui diffuse, des ressources importantes, en sécurité, en complexité de mise en place et d'administration, en puissance de calcul, et en bande passante. Et il implique également pour celui qui lit des trucs et poste des commentaires, une impuissance dans le choix de l'application et des difficultés pour contrôler et limiter le comportement de celle-ci ("Empêcher ce site de générer des boîtes de dialogue supplémentaires", c'est fou d'en arriver là, non ?).
Donc voilà, le bilan : les choix techniques faits, et le manque de recul, y compris du monde du libre, face à la "webbisation" d'Internet, font que l'utilisateur chez lui avec son serveur basse consommation et sa bande passante limitée, il ne peut pas, de façon autonome, poster un billet pour dire "regardez mon chat qui monte une échelle", mettre un lien vers une vidéo qu'il héberge (même s'il n'est pas le seul à l'héberger, merci BitTorrent), et le faire avec un semblant d'égalité par rapport à Twitter, Youtube, Facebook et leur formidable puissance de feu. Avec d'autres protocoles, et/ou une extension du Web dans d'autres directions que "faire de l'OpenGL et un OS en javascript", il pourrait. Et ça serait bon pour Internet et bon pour les internautes.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: ca fait peur
Posté par Grunt . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing". Évalué à 5.
Je n'ai jamais dit que le code côté client c'était mal. Je dis qu'un truc comme Gmail ça s'appelle par exemple Thunderbird. Avec du code choisi par l'utilisateur (il peut remplacer Thunderbird par Kmail ou Evolution) indépendamment du service (t'as déjà utilisé le webmail de Yahoo chez Google ou l'inverse ? Ah zut on peut pas). Avec une économie de ressource incroyable à fonctionnalités égales. Avec de bien plus grandes facilités pour héberger soi-même le service (même si le code source de Gmail était libre, je préfère mille fois mieux me taper l'installation d'un postfix+dovecot côté serveur et Thunderbird côté client, que l'installation d'un Gmail-like sur un LAMP).
D'un autre côté, si tu laisses l'utilisateur choisir son application cliente au lieu d'en proposer une toute faite en javascript, je suis absolument certain qu'elle finira par proposer de garder en mémoire les données saisies au lieu de les retaper. Exemple, 100% des clients de messagerie instantanée, en cas de mot de passe erroné ou de données rejetées par le serveur, gardent dans les champs déjà remplis les données saisies. Par contre, des sites Web qui te bennent tout, ou qui déclarent comme invalide un truc qui est valide, j'en ai vu ma dose.
Exemple, le webmail d'Orange :
http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-legales.html
Si c'est pour coder des applications aussi merdiques et les imposer à l'utilisateur final, il vaut franchement mieux le laisser choisir une application qui fonctionne, qui tourne chez lui.
Pas la peine, il existe : XMPP. Et il est à tous points de vue de meilleure qualité que le bordel mis en branle par l'interface de Twitter. Que ce soit "le site Web Twitter dans un navigateur" ou bien "l'API Twitter pour faire sa propre application over HTTP".
C'est pas forcément une "meilleure idée", ce sont des idées équivalentes : FTP, rsync, NFS, BitTorrent. Des protocoles standards qui permettent de copier des données publiées, et qui peuvent offrir des fonctionnalités supplémentaires par rapport à HTTP. rsync est réellement fait pour ne copier que ce qui a changé. BitTorrent permet de répartir la charge entre tous les gens ayant déjà téléchargé le fichier.
BitTorrent, en l'état, n'est pas utilisable pour cet usage, on est d'accord. Mais il ne lui manque pas grand chose. HTTP non plus n'a pas été prêt pour le streaming tout de suite (sans les requêtes "Partial Content" qui permettent de récupérer la vidéo à partir d'un certain délai, ça serait franchement moins pratique. Je pense que tu vois mieux que moi de quoi je parle sur ce point :D)
Tu connais l'histoire des abonnés Free chez qui Youtube il rame tellement qu'ils ouvrent la page, et patientent dix minutes pour regarder une vidéo de deux minutes ? Je trouve qu'ils ressemblent furieusement à des gens qui ont appris à se passer du caractère instantané du streaming. Ils ont besoin de streaming, la réalité physique du réseau (des tuyaux congestionnés, tout simplement) leur apprend à s'en passer.
Si c'était possible de "lire du BitTorrent en streaming" je suis certain qu'avec une dizaine de seeders (autrement dit, une dizaine de gens ont vu la vidéo récemment) ça irait plus vite s'ils cliquaient sur le lien "torrent-streaming" que sur le lien "Youtube".
Je t'explique ça avec plaisir. Le RTSP, je peux le lire dans VLC, ou dans mplayer si VLC me plaît pas/plante chez moi/n'est pas dispo sur mon OS. Je peux l'enregistrer. Je peux le mettre sur pause avec le raccourci que je connais par coeur de mon "lecteur qui lit toutes mes vidéos". Je peux le minimiser et continuer à lire le texte de la page Web en n'écoutant que le son, parce que l'image c'est juste quelqu'un qui parle et ça distrait plus qu'autre chose. Ouais, c'est une bonne idée en fait, au lieu d'incruster dans une page Web une application Flash (ou sa version moderne, une balise < video >, qui contraint à utiliser le lecteur intégré au navigateur), un lien "rtsp://" c'est mieux. Bien mieux à tous points de vue. Ça fait moins "fancy kikoolol 2.0", mais c'est carrément plus pratique. Genre, je vois l'article, je peux décider de commencer à télécharger la vidéo, lire tout l'article, puis lire la vidéo, si ma connexion est pas terrible. Avec du YouMotion incrusté ça demande des manipulations rusées, différentes selon chaque site, à base de "je lance la lecture, je baisse le son, je mets sur pause, je vérifie que la barre de chargement, si y'en a une, est pleine, je remets au début, je remonte le son, je relance la lecture".
556
C'est grave docteur ? La terre va arrêter de tourner ?
Ça c'est le beau protocole bisounours, et je suis d'accord avec toi sur ce point. Mon problème, c'est que, de facto, le protocole tu l'utilises dans 99,9% des cas avec l'application choisie par le fournisseur du service. Et cette application se présente sous la forme d'une URL HTTP qui ouvre une page dans laquelle se "passent des choses" qui sont, toutes ou presque, hors de contrôle de l'utilisateur lambda.
Maintenant, je vais te dire comment ça aurait pu, ou ça peut tourner, ce genre d'histoires. En prenant l'exemple des XEP (extensions au protocole XMPP). T'as un protocole de base (XMPP), on se rend compte qu'il permet de faire pas mal de choses, on regroupe des usages similaires dans des XEP histoire de pas éparpiller les implémentations. Un mélange de souplesse et d'intéropérabilité.
Sur le Web, le même schéma pourrait être appliqué. Combien de sites d'information se présentent sous l'aspect "article - ressources externes (vidéos, liens..) - commentaires" ? Des centaines, voire des milliers. Actuellement ce sont des milliers d'applications Web qui font toute la même chose (d'un point de vue fonctionnalités). Proposer (comme j'ai tendance à le faire) de remplacer ce bordel par des serveurs NNTP en réservant le droit d'initier un fil de discussion à ceux qui gèrent le serveur de news, c'est peut-être un peu exagéré. Mais on pourrait imaginer une vraie standardisation du modèle HTTP actuel, qui aboutirait à ce que l'utilisateur final ait un client dédié à la "lecture de journaux", qui saurait où taper pour avoir l'article, pour avoir la/les vidéos, pour lire/publier les commentaires. Autrement dit, chaque utilisateur choisit parmi plusieurs applications et garde la même sur chaque site. Au lieu d'avoir, comme actuellement, une application liée à un site. C'est pas sympa et ergonomique, comme idée ?
Je parle (même si ça n'en a pas l'air) du point de vue de l'utilisation finale, tant pour celui qui consulte l'information que pour celui qui va la diffuser et/ou l'héberger. Et je montre du doigt plusieurs obstacles à une "libération d'Internet", ou "libération du Web" si tu veux. Les messages flippant des navigateurs sont un de ces obstacles, qui n'est pas présent sur d'autres clients destinés à d'autres protocoles (où on mentionne simplement la non validité du certificat, où on accepte d'associer un certificat auto-signé à un serveur particulier, sans faire déborder cette acceptation sur tous les serveurs, et en prévenant si le certificat change).
Et, pour résumer, je dirais que le Web, dans sa forme actuelle, implique nécessairement, pour celui qui publie, qui diffuse, des ressources importantes, en sécurité, en complexité de mise en place et d'administration, en puissance de calcul, et en bande passante. Et il implique également pour celui qui lit des trucs et poste des commentaires, une impuissance dans le choix de l'application et des difficultés pour contrôler et limiter le comportement de celle-ci ("Empêcher ce site de générer des boîtes de dialogue supplémentaires", c'est fou d'en arriver là, non ?).
Donc voilà, le bilan : les choix techniques faits, et le manque de recul, y compris du monde du libre, face à la "webbisation" d'Internet, font que l'utilisateur chez lui avec son serveur basse consommation et sa bande passante limitée, il ne peut pas, de façon autonome, poster un billet pour dire "regardez mon chat qui monte une échelle", mettre un lien vers une vidéo qu'il héberge (même s'il n'est pas le seul à l'héberger, merci BitTorrent), et le faire avec un semblant d'égalité par rapport à Twitter, Youtube, Facebook et leur formidable puissance de feu. Avec d'autres protocoles, et/ou une extension du Web dans d'autres directions que "faire de l'OpenGL et un OS en javascript", il pourrait. Et ça serait bon pour Internet et bon pour les internautes.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.