Geckozone

Benoit a écrit :Ce n'est pas le fait que ce soit technique, c'est que que c'est tout à fait anecdotique comme terme.

Qui sait si ça ne va pas être le prochain terme à la mode, après Ajax, Web 2, le Pipelining
Bon, c'est vrai que pour l'instant c'est encore confidentiel. Mais le but de l'extension c'est aussi de le démocratiser et de l'ammener à portée du maximum de monde...

Benoit a écrit :Attention, je ne veux pas dire qu'il ne faut pas essayer d'expliquer ce que c'est, au contraire ! Mais la case à cocher doit rester proche de ce que l'utilisateur va trouver dans les références sur Internet. Que s'il rencontre un problème et qu'il voit écrit quelque part que ça pourrait être causé par un serveur ne supportant pas le pipelining il comprenne tout de suite quoi faire.

Ok, vu comme ça ça se tient...

Ce qu'on pourrait faire c'est donc utiliser "Octetoduc" et dans l'explication préciser qu'en anglais ça s'appelle "Pipelining" en anglais, histoire que les gens sachent quoi rechercher...

Et rien ne nous empêche de décrire plus précisément ce que ça fait que dans la VO que je trouve très partiale... je pense préciser que "Attention, multiplier le nombre de connexions avec un serveur peut le surcharger et finalement le ralentir" ou quelque chose comme ça, parce que dans la vo c'est juste dit "ça peut accélérer", je trouve limite...

calimo a écrit :Ce qu'on pourrait faire c'est donc utiliser "Octetoduc" et dans l'explication préciser qu'en anglais ça s'appelle "Pipelining" en anglais, histoire que les gens sachent quoi rechercher...

voir directement acoler les deux mots octetoduc (pipelining) quand on à la place...

calimo a écrit :Et rien ne nous empêche de décrire plus précisément ce que ça fait que dans la VO que je trouve très partiale... je pense préciser que "Attention, multiplier le nombre de connexions avec un serveur peut le surcharger et finalement le ralentir" ou quelque chose comme ça, parce que dans la vo c'est juste dit "ça peut accélérer", je trouve limite...

Si c'est possible, personelement je suis pour à 200%... Cela permet de démistifier ces options... Et si pour les néofit cela ne serviras à rien, cela empecheras peut-être une peux les amateur de mettre un peux n'importe quoi et faire au final pire que mieux et surtout de relayer que c'est magnifique puis reprit telle qu'elle... Car s'il obtienne peux de résultat avec 32 requette simultaner sur des gros site telle google, sur d'autre serveur plus petit avec des centaine de grosse images cela peux être catastrophique...

jv2759 a écrit :

Benoit a écrit :jv tu confonds requête et connexion.

Je n'est pas l'impretion???

Ok moi-même j'ai écrit "requête" alors qu'il faudrait plutôt dire "paquet"

allows multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses.

Sur une connection on peux faire plusieur requette lancer en même temps ou qui ce suivent.

Je ne suis pas sûr de te suivre donc je reprends du début

Le principe d'HTTP c'est que le client ouvre une connexion (un socket) en envoyant un paquet contenant une requête. Si le serveur ne comprend que HTTP 1.0, il envoie sa réponse (éventuellement en plusieurs paquets) et ferme la connexion. Le client doit en ouvrir une nouvelle et ainsi de suite. En pratique il va en ouvrir jusqu'à quatre à la fois vers le même serveur (à partir de la seconde requête au plus tôt, puisque c'est dans la réponse à la première qu'il aura l'adresse des autres fichiers nécessaires tels que des images, des feuilles de style, etc.)

Si le serveur comprend HTTP 1.1, il ne ferme pas la connexion après avoir répondu, il la laisse ouverte (elle est persistante). Le client peut lui envoyer sa requête suivante dessus pendant un certain temps (keep-alive). On gagne ainsi le temps d'établissement de la connexion à chaque fois. Ensuite, chacun "parle" à son tour. Le client demande l'élément suivant, le serveur envoie sa réponse, etc. S'il n'y a pas d'activité sur la connexion après un certain temps, le serveur ferme le socket quand même pour libérer un port. En théorie cela rend HTTP 1.1 plus lent, mais surcharge moins les serveurs (donc en pratique ça peut aller plus vite).

Le pipelining maintenant : si le serveur a répondu la première fois en HTTP 1.1 (en renvoyant le résultat de la première requête), et que le pipelining est activé, le client sait qu'il peut alors envoyer plusieurs requêtes à la suite dans un même paquet, 8 au maximum. Le serveur ayant reçu ces requêtes envoie lui-même toutes les réponses à la suite sur le socket. On gagne là non pas sur le temps d'établissement de la connexion, mais sur le nombre d'aller-retours. Dans ce cas, on va toujours plus vite que HTTP 1.0 puisque dès la deuxième requête, on peut tout demander (et recevoir) en une fois sans devoir ouvrir de nouvelle(s) connexion(s). Enfin, en activant la compression, on réduit encore le nombre de paquets échangés.

Note pour calimo : je ne sais pas si l'extension permet de choisir le nombre de requêtes utilisées pour le pipelining ? Si oui il faudrait préciser que ça ne sert à rien d'en mettre plus que 8

on a comprit en gros la même chose... Ils y as juste l'histoir des paquet dans le sence client -> serveur que je n'avais pas vue... Le reste c'est casiment la même chose, avec juste le fait que tu as utiliser un language plus compréhensible...

Ok c'est nettement plus clair comme ça

Benoit a écrit :Note pour calimo : je ne sais pas si l'extension permet de choisir le nombre de requêtes utilisées pour le pipelining ? Si oui il faudrait préciser que ça ne sert à rien d'en mettre plus que 8

J'ai :
Activer le pipelining
Activer le pipelining dès la première requête
Activer le pipelining avec les proxy
Maximum de requêtes par pipe-line

Par défaut ce nombre de requêtes est 2 je crois...
Mais la question est : s'agit-il du maximum de pipe-lines ouverts, ou du nombre de requête par pipe-line ? En anglais c'est "Max Pipelining Requests"... je penche pour le deuxième, le nombre de pipe-lines ouverts étant géré par le "Max Persistent Connections Per Server" qu'on a dans les options de connexion ?

C'est un vrai bordel tout ça

calimo a écrit :Mais la question est : s'agit-il du maximum de pipe-lines ouverts, ou du nombre de requête par pipe-line ? En anglais c'est "Max Pipelining Requests"... je penche pour le deuxième, le nombre de pipe-lines ouverts étant géré par le "Max Persistent Connections Per Server" qu'on a dans les options de connexion ?

Oui c'est bien ça.

C'est un vrai bordel tout ça

Ce n'est pas pour rien que ces options ne sont normalement pas exposées aux utilisateurs

Pour ceux qui sont sur le coup, je signale juste cette mise à jour :
https://addons.mozilla.org/extensions/m ... ox&id=1269
- des octets plein les tuyaux ! 8)

La MAJ de l'extension va plus vite que moi On en est à la 0.7.4.
Je tente de faire quelque chose et je vous tiens au courant...

Essayez la version 0.7.4 : http://extensions.geckozone.org/xpi/moz ... -0.7.4.xpi

On verra selon les résultats du sondage si on garde celle-la (j'envoie la traduction à l'auteur) ou si on modifie le pipe-line...

tiens je reprends mes vieilles habitudes...

dans pref-fasterfox.dtd :

66 <!ENTITY pipelining.desc "Le pipelining permets >permet

80 dites adieux > adieu

Goofy a écrit : tiens je reprends mes vieilles habitudes...

Vieilles peut-être, mais bonnes, et toujours aussi efficaces
Merci
Je laisse le sondage quelques jours pour voir si la tendance s'inverse... (en cas de "victoire" de la deuxième option, il est bien évident que je mentionnerai quand-même le terme "pipelining" )

Je n'ai pas suivi la discussion mais j'ai quand même voté pour «pipelining», tellement je trouve laid le terme octetoduc, désolé pour ses promoteurs ...
Ça se prononce «octé-to-duc», alors qu'en français le «t» final de ce mot ne se fait jamais entendre, il n'est jamais lié. Diriez-vous un octet-t-ajouté ou un octé ajouté ?

Si vous deviez choisir ce terme (que personne ne comprendra, mais bon, il faut parfois savoir forcer l'usage...), alors je suis bcp plus partisan de la proposition de jv, octeoduc, qui offre l'avantage d'une prononciation bcp plus naturelle.

En effet, du point de vue esthétique, ça se discute. Pour la liaison, l'argument ne me convainc pas, si je dis "un octet à la fois" j'aurais tendance à faire la liaison (?)...
Pipeline, octeoduc, tuyau... l'important c'est que l'usager comprenne...et je rappelle que ce qui est difficile à traduire c'est "pipelining" et pas pipeline (non l'objet, mais l'action qui consiste à faire passer un gros flux de requêtes ou paquets à travers des canalisations virtuelles !)

On trouve par exemple dans l'extension :
"Activer le pipelining"
> "Activer l'octéoduc" ne serait pas beaucoup plus clair (?)
Quelque chose comme "Activer la turbo-connexion" serait peut-être plus imagé (compte-tenu qu'il existe par ailleurs un paragraphe explicatif très éclairant (merci Calimo) :
(Euh, Calimo, plutôt "proxies" au pluriel )

salut les académicien-ne-s !
ben pipelining of course, même si octéoduc est charmant ... parce que sinon, il va falloir s'attaquer (dans les traductions) aussi au mandataire distant (proxy) et aux ... heu ... biscuits (cookies). pour ce dernier, si vous vouliez une traduction, je vous proposerais bien "avoine" (mais c'est trop perso) ... on va couper la poire en deux : "croûtons".

rq : j'ai bien accepté de traduire les smilies par le 'achement explicite "émoticônes".

Goofy a écrit :(Euh, Calimo, plutôt "proxies" au pluriel )

Ha, ça dépend si tu acceptes que "proxy" soit aussi un mot français ou non

Par exemple, "des pizzas" c'est pas un pluriel correct en italien, ou à l'inverse "un spaghetti" est un singulier incorrect. Mais en français on peut.