C'est bien ce qu'explique le document : le protocole X est bien, mais il commence à avoir pas mal vécu, il a été étendu dans tous les sens, ce qui entraine parfois des incohérences entre modules ou un prix trops élever à payer (en terme de performances ou de facilité d'utilisation) pour assurer la compatibilité entre toutes les parties.
Ce que propose l'auteur d'après ce que j'ai compris au document, c'est de reprendre le protocole X en y intégrant dès le debuts certaines choses qui lui manque et qu'il serait difficile d'intégrer, malgrès son caractère extensible.
Le protocle Y est un successeur de X, donc l'auteur ne jette pas tout :l'auteur veut réécrire le protocole pour lui faire profiter de 20 ans d'expérience et rendre le tout cohérent et plus en phase avec les avancées techniques.
De plus, je crois qu'il pense clairement implémenter une couche de compatibilité X/Y pour assurer la transition (si elle doit se faire).
C'est pourquoi, je trouve sa démarche très intéressante. Je pensais également que le protocole X étant vraiment bon. À lire le PDF, je me rend compte que pas de choses peuvent être améliorer.
[^] # Re: Y : un remplaçant pour X ?
Posté par Fanf . En réponse à la dépêche Y : un remplaçant pour X ?. Évalué à 3.
Ce que propose l'auteur d'après ce que j'ai compris au document, c'est de reprendre le protocole X en y intégrant dès le debuts certaines choses qui lui manque et qu'il serait difficile d'intégrer, malgrès son caractère extensible.
Le protocle Y est un successeur de X, donc l'auteur ne jette pas tout :l'auteur veut réécrire le protocole pour lui faire profiter de 20 ans d'expérience et rendre le tout cohérent et plus en phase avec les avancées techniques.
De plus, je crois qu'il pense clairement implémenter une couche de compatibilité X/Y pour assurer la transition (si elle doit se faire).
C'est pourquoi, je trouve sa démarche très intéressante. Je pensais également que le protocole X étant vraiment bon. À lire le PDF, je me rend compte que pas de choses peuvent être améliorer.