Sauf que ton « translateur » est dépendant du protocole,
Dictionnaire! Le translateur ne dépend pas du protocole, il a un dictionnaire qui l'alimente.
Mais attends, qu'est-ce que vi fait… Ah oui, il la aussi un dictionnaire (ASCII table, qui va transformer un octet en une série de pixels compréhensibles par toi), sauf qu'il n'est pas optimisé pour la taille (peut mieux faire pour HTML).
Moi c’est une fonctionnalité que j’utilise tous les jours.
Toi. Mais toi, tu ne représentes pas tout le monde.
Encore une fois, « expliquez moi votre besoin, je vous dirai comment vous en passer »
Est-ce que sur ta machine tu as tous les paquets avec toutes les options de débugging au cas où un gus voudrait debugger? Non, tu as les paquets en mode "release", pour des question de place et performance. Ben la, HTTP et compagnie, on a mis le mode debug pour tout le monde, et les gens qui debuggent ne veulent pas qu'on leur retire leur mode debug. Mais je me demande juste pourquoi tu n'as pas toute ta machine en mode debug pour la même raison.
Et de toute façon, une fois que ta requête tient dans un paquet TCP, ça sert à rien de t’échiner à la réduire, tu auras du padding de toute façon…
Oui et non :
- avec les data, ça peut dépasser. Et gagner un paquet ça peut être utile
- perfs : un client peut s'en foutre (et encore avec les mobiles), mais pour un serveur entre parser 1 octet ou 3 octets pour le "GET", ça change un peu en perfs.
Bref, ça dépend du besoin. Si le besoin est debug pour tout le monde, pourquoi pas, mais si le besoin est un gain en débit et perfs, ça se défend.
et encore une fois, ça n’empêche pas d'optimiser ailleurs.
Je ne changerai pas le monde, le monde a choisi HTTP, XML etc… (et s'amuse à optimiser ensuite, genre compression, qui n'est pas lisible par ton vi), je vivrai avec (et avec les logs Apache à ralonge car en mode texte aussi, avec une adresse IPv4 qui prend 15 octets à la place de 4), les protocoles "non texte" n'ont pas le vent en poupe en ce moment (qui sait, ça reviendra peut-être). Je trouve ça juste dommage que le mode debug je bouffe de la place soit actif pour tout le monde.
[^] # Re: Entêtes binaires???
Posté par Zenitram (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 3. Dernière modification le 25 mai 2012 à 13:09.
Dictionnaire! Le translateur ne dépend pas du protocole, il a un dictionnaire qui l'alimente.
Mais attends, qu'est-ce que vi fait… Ah oui, il la aussi un dictionnaire (ASCII table, qui va transformer un octet en une série de pixels compréhensibles par toi), sauf qu'il n'est pas optimisé pour la taille (peut mieux faire pour HTML).
Toi. Mais toi, tu ne représentes pas tout le monde.
Est-ce que sur ta machine tu as tous les paquets avec toutes les options de débugging au cas où un gus voudrait debugger? Non, tu as les paquets en mode "release", pour des question de place et performance. Ben la, HTTP et compagnie, on a mis le mode debug pour tout le monde, et les gens qui debuggent ne veulent pas qu'on leur retire leur mode debug. Mais je me demande juste pourquoi tu n'as pas toute ta machine en mode debug pour la même raison.
Oui et non :
- avec les data, ça peut dépasser. Et gagner un paquet ça peut être utile
- perfs : un client peut s'en foutre (et encore avec les mobiles), mais pour un serveur entre parser 1 octet ou 3 octets pour le "GET", ça change un peu en perfs.
Bref, ça dépend du besoin. Si le besoin est debug pour tout le monde, pourquoi pas, mais si le besoin est un gain en débit et perfs, ça se défend.
et encore une fois, ça n’empêche pas d'optimiser ailleurs.
Je ne changerai pas le monde, le monde a choisi HTTP, XML etc… (et s'amuse à optimiser ensuite, genre compression, qui n'est pas lisible par ton vi), je vivrai avec (et avec les logs Apache à ralonge car en mode texte aussi, avec une adresse IPv4 qui prend 15 octets à la place de 4), les protocoles "non texte" n'ont pas le vent en poupe en ce moment (qui sait, ça reviendra peut-être). Je trouve ça juste dommage que le mode debug je bouffe de la place soit actif pour tout le monde.