Si cette problématique est "contrôler le plus possible le code exécuté par l'utilisateur" je suis d'accord. Mais je trouve dommage de ne pas prendre de recul critique sur cette exigence du "Web 2.0", qui est, finalement, une resucée moins performante, pleine de publicités, centralisée, limitée, de ce que les internautes faisaient y'a 20 ans : Échanger des fichiers. Discuter en temps réel. Avoir une discussion publique, organisée par fils de discussion. S'envoyer des messages différés. Avant même que le Web n'existe on pouvait faire ça (y compris la causette, CF IRC ou talk). Maintenant 99% des utilisateurs le font en utilisant une machine virtuelle nommée navigateur, qui exécute des applications choisies par le fournisseur du service. C'est.. problématique, en effet.
Ben ouais, mais t'es mignon, le W3C a mit JS dans la spec depuis un bail, parce que, ben, on en a besoin.
Tu peux tourner le pb dans tous les sens, on a en a besoin, avoir une techno de présentation 100% statique, ça pose des pb et on peut pas faire sans.
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.
Bien évidemment je pars du principe que des données volontairement corrompues ne mettrons pas en danger ton serveur, sinon ce serait du délire de les valider avec du code qui tourne chez l'utilisateur final et hostile.
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.
On a réinventé TCP/IP, super :)
Pour autant que je sache, TCP et IP ne sont pas des protocoles applicatif. Je peux me tromper cela dit, hein.
Moins de ressources réseau et CPU gâchées
Mais en quoi HTTP bouffe des resources? Le protocole est simplissime, tellement simple que tu l'implementes sur tcp avec 2 fois rien (je sais, je le fais, ça tiens en 200 lignes). C'est sur que si tu veux garder une connexion permanente entre le serveur et le client, HTTP ça va pas être au poil, apres utiliser un protocole stateful pour du stateless, ça va être le meme merdier...
Implementer un salon de discussion over HTTP, oui, c'est con.
A peu près aussi con que réinventer un protocole dédie pour poster 140 characteres sur une ressource.
Maintenant, si t'as une meilleur idée que HTTP pour transférer des données sans authentification, je suis toute ouïe.
Si l'overhead de qq dizaines d'octets est trop pour toi, va falloir argumenter. Serieusement.
Je préfère le bon vieux démon IRC, Jabber, mail, ce que tu veux, qui va simplement "faire le truc dont il est question" et dont les logs sont lisibles :)
Non, ce qu'il se passe c'est que tu comprends pas ce qu'il se passe, et que tu clames qu'il faut se passer de ce genre de fonctionnalité parce que tu comprends pas comment ça marche.
C'est simple pourtant. Ca a rien de bien complique pourtant.
Juste parce que t'es pas foutu de comprendre comment ça marche, ça le rend pas inutile.
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".
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 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.
Ah, bien sûr ça implique de communiquer avec des protocoles à peu près standard et de laisser l'utilisateur libre de choisir son implémentation, c'est embêtant : il risque de préférer l'implémentation sans publicité.
Super, et next thing you know, tu te retrouves aver 150 protocols differents.
Et quand tu les regardes de pres, ce qu'ils font pour la plupart, c'est du CRUD sur une ressource distante. Oh. ben tient. Ca sera pas le principe de base de REST ça des fois?
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 a à voir avec la plupart des implémentations de HTTP : le client gueule comme un putois.
T'es au courant que la partie "je te gueule dessus", elle vient de SSL/TLS, pas d'HTTP?
Par contre, sur un site Web, si Firefox lui affiche l'image d'un flic en haut à gauche, et qu'il doive confirmer qu'il "comprend les risques" avant de continuer, il va laisser tomber
Gne? Donc en gros, parce qu'un client met en garde ses clients contre un vecteur d'attaque courant, HTTP, qui n'a strictement rien a voir avec le problème en question, est un mauvais protocole?
Et si iChat se met a afficher un flic pour les certifs auto signes, Jabber va devenir un mauvais protocole aussi?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: ca fait peur
Posté par pasScott pasForstall . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing". Évalué à 0.
Ben ouais, mais t'es mignon, le W3C a mit JS dans la spec depuis un bail, parce que, ben, on en a besoin.
Tu peux tourner le pb dans tous les sens, on a en a besoin, avoir une techno de présentation 100% statique, ça pose des pb et on peut pas faire sans.
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.
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.
Pour autant que je sache, TCP et IP ne sont pas des protocoles applicatif. Je peux me tromper cela dit, hein.
Mais en quoi HTTP bouffe des resources? Le protocole est simplissime, tellement simple que tu l'implementes sur tcp avec 2 fois rien (je sais, je le fais, ça tiens en 200 lignes). C'est sur que si tu veux garder une connexion permanente entre le serveur et le client, HTTP ça va pas être au poil, apres utiliser un protocole stateful pour du stateless, ça va être le meme merdier...
Implementer un salon de discussion over HTTP, oui, c'est con.
A peu près aussi con que réinventer un protocole dédie pour poster 140 characteres sur une ressource.
Maintenant, si t'as une meilleur idée que HTTP pour transférer des données sans authentification, je suis toute ouïe.
Si l'overhead de qq dizaines d'octets est trop pour toi, va falloir argumenter. Serieusement.
Non, ce qu'il se passe c'est que tu comprends pas ce qu'il se passe, et que tu clames qu'il faut se passer de ce genre de fonctionnalité parce que tu comprends pas comment ça marche.
C'est simple pourtant. Ca a rien de bien complique pourtant.
Juste parce que t'es pas foutu de comprendre comment ça marche, ça le rend pas inutile.
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".
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 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.
Super, et next thing you know, tu te retrouves aver 150 protocols differents.
Et quand tu les regardes de pres, ce qu'ils font pour la plupart, c'est du CRUD sur une ressource distante. Oh. ben tient. Ca sera pas le principe de base de REST ça des fois?
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...)
T'es au courant que la partie "je te gueule dessus", elle vient de SSL/TLS, pas d'HTTP?
Gne? Donc en gros, parce qu'un client met en garde ses clients contre un vecteur d'attaque courant, HTTP, qui n'a strictement rien a voir avec le problème en question, est un mauvais protocole?
Et si iChat se met a afficher un flic pour les certifs auto signes, Jabber va devenir un mauvais protocole aussi?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.