J'ai apprécié la lecture de l'article. Le ton léger sans trop en faire permet d'absorber plus facilement des concepts un peu rébarbatifs.
Cependant, je pense qu'il gagnerait en qualité s'il était un peu plus clair sur certains points. Voici quelques remarques et questions, qui ne sont que constructives, car je sais à quel point il est difficile d'écrire un texte de cette taille. Il s'agit du point de vue de quelqu'un qui n'y connaît pas grand chose en dév Web, mais c'est le public concerné je crois.
On crée un objet XMLHttpRequest, on lui indique l’URL de la page à télécharger
Qui ? Le client ?
Pour en recevoir, on lance une requête de longue durée, et on reçoit les messages du serveur au fur et à mesure (…) Par contre, il faut se payer la gestion de la séparation des messages. Rien ne garantit qu’on va recevoir chaque message en un coup. Il « suffit » donc d’utiliser un séparateur (par exemple un ou deux retours à la ligne).
Un gars plutôt réseau comme moi ne comprend pas pourquoi il faut séparer les messages. On reçoit les messages au fur et à mesure, donc des paquets de données (plus précisément des PDU de niveau 7). C'est le paquet qui sépare les messages non ?
Sans les WebSockets :
Une requête HTTP est envoyée pour avertir le serveur.
Le serveur répond OK à la requête, puis,
transmet le déplacement à tous les joueurs, y compris celui qui a joué, par simplicité. Ce déplacement est reçu par le joueur via la requête de longue durée.
Avec les WebSockets :
Le joueur envoie le coup par la WebSocket
Le serveur répond ok dans la WebSocket
Le serveur envoie le déplacement à tous les joueurs, dont à ce joueur à travers cette même WebSocket.
C'est un peu exactement la même chose, je ne vois pas la différence.
Elle réside peut-être là :
Sauf que dans la vraie vie, le déplacement peut être reçu avant la réponse OK par le joueur.
Mais je ne comprends pas du tout pourquoi.
Ce serait quand même bien d’avoir un mécanisme de communication dans les deux sens sur le web, sans se payer le coup des requêtes HTTP,
- Navigateur : Salut, une petite WebSocket, ça te dit ?
- Serveur : Ouais ouais, carrément !
- … et c’est parti pour un échange bidirectionnel endiablé
Là encore, je ne vois pas la différence avec du HTTP. Avec le HTTP, on a aussi un échange bidirectionnel : le client envoie des données au serveur, et le serveur envoie des données au client.
Ce qu'il faudrait expliciter vraiment (si j'ai bien compris), c'est que une fois le socket "ouvert", le serveur peut être à l'initiative d'un message vers le client, ce qui est normalement réservé au client. En fait, on peut faire un vrai "push" ici : pour recevoir des données du serveurs, on ne contente pas d'attendre le retour de requêtes envoyées au serveur. Le serveur peut de lui même initier des requêtes vers le client. Je suppose que cela sous-entend une prise en charge particulière dans les proxies et NAT.
C'est plutôt bien expliqué sur la page Wikipedia :
This is made possible by providing a standardized way for the server to send content to the client without being first requested by the client
La page https://websocket.org/quantum.html donnée en référence explique aussi les méthodes historiques (polling, long-polling, streaming).
Est-ce qu'un jour les acteurs de l'open source comprendront que l'enrobage est aussi important que le contenu ?
Avec ce nom, ce logiciel ne se développera pas, il restera au mieux confidentiel, mais tombera plus probablement dans l'oubli.
Par pitié, arrêtez avec les acronymes imprononçables.
Pour le nom, il vaut mieux un bon logiciel avec un nom peu flatteur qu'un logiciel pourri avec un joli nom (et je ne dis pas ça parce que l'éducation nationale utilise des logiciels comme Sirhen ou Apogé…).
Non, les deux sont autant importants. Un nom doit s'inscrire dans l'esprit, s'imposer comme une évidence pour être retenu, c'est pourtant simple.
Effectivement, éviter également les acronymes douteux et bricolés dans le genre du MEN. Faites-nous rêver, à la Google, Amazon and co.
Qu'est-ce qui évoque la liberté, le temps libre dégagé grâce à cet outil ? Y-a-t-il des références dans la mythologie, dans les comics, dans la culture générale ?
Effectivement, dans un cadre imposé et limité, Linux s'en sort très bien en desktop. Chez Learning Tree par exemple, il y a des PC de navigation internet mis à disposition sous Ubuntu.
En entreprise, pour des applications spécifiques, l'utilisateur n'a pas le choix : on lui impose une interface. J'ai par exemple utilisé des interfaces de saisie de tickets d'incidents en mode texte, avec moult acronymes imbuvables. Il n'y a rien d'autre à installer, le système n'évolue pas, c'est stable, tout va bien.
Là où c'est plus compliqué, c'est quand l'utilisateur a le choix. Windows ou Linux ? Et dans Linux, quelle distribution ? Pourquoi le bureau n'est pas le même que chez mon pote ?
Et ne parlons pas du côté développeurs d'applications. Par exemple, Skype pour Linux, c'est pas moins de 5 paquets différents.
# Besoin de quelques éclaircissements
Posté par tbartolone . En réponse à la dépêche Communiquer avec le serveur depuis un navigateur Web : XHR, SSE et WebSockets. Évalué à 2.
Hello
J'ai apprécié la lecture de l'article. Le ton léger sans trop en faire permet d'absorber plus facilement des concepts un peu rébarbatifs.
Cependant, je pense qu'il gagnerait en qualité s'il était un peu plus clair sur certains points. Voici quelques remarques et questions, qui ne sont que constructives, car je sais à quel point il est difficile d'écrire un texte de cette taille. Il s'agit du point de vue de quelqu'un qui n'y connaît pas grand chose en dév Web, mais c'est le public concerné je crois.
Qui ? Le client ?
Un gars plutôt réseau comme moi ne comprend pas pourquoi il faut séparer les messages. On reçoit les messages au fur et à mesure, donc des paquets de données (plus précisément des PDU de niveau 7). C'est le paquet qui sépare les messages non ?
C'est un peu exactement la même chose, je ne vois pas la différence.
Elle réside peut-être là :
Mais je ne comprends pas du tout pourquoi.
Là encore, je ne vois pas la différence avec du HTTP. Avec le HTTP, on a aussi un échange bidirectionnel : le client envoie des données au serveur, et le serveur envoie des données au client.
Ce qu'il faudrait expliciter vraiment (si j'ai bien compris), c'est que une fois le socket "ouvert", le serveur peut être à l'initiative d'un message vers le client, ce qui est normalement réservé au client. En fait, on peut faire un vrai "push" ici : pour recevoir des données du serveurs, on ne contente pas d'attendre le retour de requêtes envoyées au serveur. Le serveur peut de lui même initier des requêtes vers le client. Je suppose que cela sous-entend une prise en charge particulière dans les proxies et NAT.
C'est plutôt bien expliqué sur la page Wikipedia :
La page https://websocket.org/quantum.html donnée en référence explique aussi les méthodes historiques (polling, long-polling, streaming).
Merci
# pourquoi ?
Posté par tbartolone . En réponse à la dépêche CentOS se saborde‑t‑elle ?. Évalué à -4.
Un choix bien évidemment ridicule de la part de CentOS
Au lieu de cela, il auraient pu créer un projet parallèle, tout en conservant CentOS.
Décidemment, jamais grand chose de stable très longtemps dans le monde de l'open source
[^] # Re: tar bomb
Posté par tbartolone . En réponse au journal Utilisation d’un TPM pour l’authentification SSH. Évalué à 0.
Ca marche avec jq et find aussi
[^] # Re: <noob>A quoi ça sert ?</noob>
Posté par tbartolone . En réponse au journal Utilisation d’un TPM pour l’authentification SSH. Évalué à 3.
Superbe, merci pour vos réponses.
# <noob>A quoi ça sert ?</noob>
Posté par tbartolone . En réponse au journal Utilisation d’un TPM pour l’authentification SSH. Évalué à 2.
Ca serait pas mal de dire quelle est l'utilité en introduction ?
Est-ce que ça permet de s'authentifier avec un jeton ? (non)
Ou d'utiliser l'authentif biométrique du PC ? Ou de faire du SSO ?
Merci
# chiffrage =/= chiffrement
Posté par tbartolone . En réponse à la dépêche BleachBit 4.0 est disponible. Évalué à 7.
hello hello
chiffrer une devis = chiffrage
chiffrer un texte pour le cacher = chiffrement
bisous :-*
# Ce nom
Posté par tbartolone . En réponse à la dépêche WikHaiePédia. Évalué à 10.
Désolé mais le nom est vraiment pas terrible. Je n'interviens jamais sur Linuxfr mais là…
Le projet gagnerait en crédibilité avec un autre nom, pourquoi ne pas faire appel à la communauté pour des propositions ?
# anglicisme
Posté par tbartolone . En réponse à la dépêche LoL, une affaire sérieuse, compte‐rendu de l’avant‐première. Évalué à 0.
"Définitivement oui."
Attention aux anglicismes contre-sens.
Définitivement = une fois pour toutes.
Absolument, oui
http://lecons.ssz.fr/node/138
[^] # Re: inspiration
Posté par tbartolone . En réponse à la dépêche FlOpEDT : un nouveau logiciel libre de gestion des emplois du temps !. Évalué à 10.
Merci pour ce logiciel et ces efforts,
Cependant…
Est-ce qu'un jour les acteurs de l'open source comprendront que l'enrobage est aussi important que le contenu ?
Avec ce nom, ce logiciel ne se développera pas, il restera au mieux confidentiel, mais tombera plus probablement dans l'oubli.
Par pitié, arrêtez avec les acronymes imprononçables.
Non, les deux sont autant importants. Un nom doit s'inscrire dans l'esprit, s'imposer comme une évidence pour être retenu, c'est pourtant simple.
Effectivement, éviter également les acronymes douteux et bricolés dans le genre du MEN. Faites-nous rêver, à la Google, Amazon and co.
Qu'est-ce qui évoque la liberté, le temps libre dégagé grâce à cet outil ? Y-a-t-il des références dans la mythologie, dans les comics, dans la culture générale ?
[^] # Re: Administration vs. utilisation
Posté par tbartolone . En réponse à la dépêche Livre Red Hat Enterprise Linux - CentOS chez ENI (2ème édition). Évalué à 2.
Effectivement, dans un cadre imposé et limité, Linux s'en sort très bien en desktop. Chez Learning Tree par exemple, il y a des PC de navigation internet mis à disposition sous Ubuntu.
En entreprise, pour des applications spécifiques, l'utilisateur n'a pas le choix : on lui impose une interface. J'ai par exemple utilisé des interfaces de saisie de tickets d'incidents en mode texte, avec moult acronymes imbuvables. Il n'y a rien d'autre à installer, le système n'évolue pas, c'est stable, tout va bien.
Là où c'est plus compliqué, c'est quand l'utilisateur a le choix. Windows ou Linux ? Et dans Linux, quelle distribution ? Pourquoi le bureau n'est pas le même que chez mon pote ?
Et ne parlons pas du côté développeurs d'applications. Par exemple, Skype pour Linux, c'est pas moins de 5 paquets différents.