arnaudlevy/quentin.dufour.io
1
0
Fork 0
forked from quentin/quentin.dufour.io
Code Pull requests 1 Activity

fix typo

Browse source
This commit is contained in:
Quentin 2024-02-07 11:36:26 +01:00
parent a4a1abd5af
commit 5d324d1209
Signed by untrusted user: quentin
GPG key ID: E9602264D639FF68
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
_posts/2024-02-06-fosdem.md
View file

@ -27,7 +27,7 @@ C'était une expérimentation qui a été très fructueuse : les développeur-eu
La journée a commencé par la dimension "protocole" des emails : pourquoi il faut abandonner STARTTLS, les subtilités d'IMAP, et l'intégration d'Unicode dans les emails. Globalement, c'est très convaincant qu'il ne faut *vraiment* pas utiliser STARTTLS, et encore moins l'implémenter, c'est un nid à problème. Rien de nouveau lors de la présentation sur IMAP, deux points qui m'ont bien plu : on peut pas lexer IMAP, *knowledge is disappearing* et la subtilité des literals dans IMAP. La journée a commencé par la dimension "protocole" des emails : pourquoi il faut abandonner STARTTLS, les subtilités d'IMAP, et l'intégration d'Unicode dans les emails. Globalement, c'est très convaincant qu'il ne faut *vraiment* pas utiliser STARTTLS, et encore moins l'implémenter, c'est un nid à problème. Rien de nouveau lors de la présentation sur IMAP, deux points qui m'ont bien plu : on peut pas lexer IMAP, *knowledge is disappearing* et la subtilité des literals dans IMAP.
C'est emersion (Simon) qui a d'abord essayé d'écrire un lexer+parser pour IMAP, et ça ne marche pas. Les lexer+parser, c'est vraiment la façon élégante, qu'on t'apprend quand tu fais de la théorie des langages, mais ça oblige de concevoir ton langage avec des contraintes, pour pas qu'il soit ambigu. IMAP a été conçu de façon très organiquem, et ne répond pas à ces critères. Du coup c'est moins élégant, moins efficace, mais on utilise un parser combinator. D'ailleurs j'en étais venu à la même conclusion pour les emails (c'est à dire IMF/MIME). C'est emersion (Simon) qui a d'abord essayé d'écrire un lexer+parser pour IMAP, et ça ne marche pas. Les lexer+parser, c'est vraiment la façon élégante, qu'on t'apprend quand tu fais de la théorie des langages, mais ça oblige de concevoir ton langage avec des contraintes, pour pas qu'il soit ambigu. IMAP a été conçu de façon très organique, et ne répond pas à ces critères. Du coup c'est moins élégant, moins efficace, mais on utilise un parser combinator. D'ailleurs j'en étais venu à la même conclusion pour les emails (c'est à dire IMF/MIME).
En effet les savoirs disparaissent. On a pu voir ça sur Cobol, on a le cas pour les emails. Ça vient heurter des croyances, du progrès linéaire sur tous les aspects, En effet les savoirs disparaissent. On a pu voir ça sur Cobol, on a le cas pour les emails. Ça vient heurter des croyances, du progrès linéaire sur tous les aspects,
y compris sur les savoirs. Cette critique n'est pas nouvelle, mais elle est toujours bonne à rappeler : les connaissances, le savoir, ça s'entretient. y compris sur les savoirs. Cette critique n'est pas nouvelle, mais elle est toujours bonne à rappeler : les connaissances, le savoir, ça s'entretient.