Désolé mais j'ai pas tout lu. Enfin j'ai lu pour de vrai la moitié, puis j'ai compris et j'ai donc arrêté. J'ai compris que tu as décidé de pondre un pavé parsemé de moi quand j'ai vraiment bossé pour de vrai sur les RFC j'ai vu ceci-cela pour essayer de gagner par KO poids + argument d'autorité.
Puisque je me réfère aux RFCs, oui c'est des arguments d'autorités.
Ou alors malgré ton boulot apparemment technique, tu as une conception de l'architecture logicielle très archaïque et brouillonne où tout serait corrélé, où ton modèle de données ne serait pas séparé ni séparable de ton interface qui reçoit les courriels, donc si y a pas le champ tel que tu l'attends exactement tout pète. Ça me parait tellement basique que je sais même pas comment l'expliquer simplement. Pense aux compilateurs qui ont généralement un modèle interne AST qui permet plus de choses que le langage dans lequel le programmeur a écrit.
Pour le coup, j'ai aussi pas mal d'expérience dans les compilateurs (et ce n'est pas très étonnant puisque je suis dans la communauté OCaml). Et oui, la résilience du logiciel par rapport aux emails est très importantes - encore aujourd'hui, j'y travaille car cela concerne surtout des cas particuliers issus d'emails spécifiques (c'est donc désormais un travail empirique).
Mais c'est tout mon propos, cette résilience s'applique avant même le MUA. Elle s'applique dès le standard. Ce qui fait qu'avant même le MUA, tu as déjà tout et n'importe quoi. Et c'est là où je dis que la difficulté d'un MUA est déjà, en partie, issue du standard.
Mon deuxième propos, c'est que de cette complexité inhérente, les concepteurs de MUA (ce dont je ne suis pas) font des choix sur la manière de traiter un email (avec ces histoires de bruit et de convention imposé par les providers) qui ne correspondent pas forcément à tout le monde - après, oui on arrive, après tant d'années, à trouver des concepts communs.
Enfin mon troisième propos, c'est de considérer cette caractéristique qu'est cette complexité comme une qualité appartenant complétement au medium de la communication et qu'on a besoin de cette liberté effroyable de la mise en forme d'un email - puisque les standards ne parle que de la forme.
PS: plus bas quelqu'un parle d'HTML. Mais en vérité c'est le même problème:
la complexité de parser du HTML
les choix des différents navigateurs d'interpréter l'HTML (le clivage IE/FF était - et reste encore dans une moindre mesure - le plus parlant)
la considération de cette complexité comme une qualité intrinsèque à ce que peut être un medium de communication
[^] # Re: Retour depuis le turfu
Posté par Dinosaure (site web personnel) . En réponse au journal À la recherche des clients mail sous Linux. Évalué à 1.
Puisque je me réfère aux RFCs, oui c'est des arguments d'autorités.
Pour le coup, j'ai aussi pas mal d'expérience dans les compilateurs (et ce n'est pas très étonnant puisque je suis dans la communauté OCaml). Et oui, la résilience du logiciel par rapport aux emails est très importantes - encore aujourd'hui, j'y travaille car cela concerne surtout des cas particuliers issus d'emails spécifiques (c'est donc désormais un travail empirique).
Mais c'est tout mon propos, cette résilience s'applique avant même le MUA. Elle s'applique dès le standard. Ce qui fait qu'avant même le MUA, tu as déjà tout et n'importe quoi. Et c'est là où je dis que la difficulté d'un MUA est déjà, en partie, issue du standard.
Mon deuxième propos, c'est que de cette complexité inhérente, les concepteurs de MUA (ce dont je ne suis pas) font des choix sur la manière de traiter un email (avec ces histoires de bruit et de convention imposé par les providers) qui ne correspondent pas forcément à tout le monde - après, oui on arrive, après tant d'années, à trouver des concepts communs.
Enfin mon troisième propos, c'est de considérer cette caractéristique qu'est cette complexité comme une qualité appartenant complétement au medium de la communication et qu'on a besoin de cette liberté effroyable de la mise en forme d'un email - puisque les standards ne parle que de la forme.
PS: plus bas quelqu'un parle d'HTML. Mais en vérité c'est le même problème: