Ceci rajoute un bruit dans le traitement qui pourrait être ignoré mais c'est justement à ce moment là qu'on prends position.
On prend position sur "ce que mon MUA de 2016 arrivera à tirer de tes vieux mails" mais pas forcément "ce que tu seras encore en droit de faire avec ton logiciel qui te plait".
En cela, on peut considérer comme tu le dis un système avec des tags (mais pourquoi on utiliserait pas les dossiers ?)
Parce qu'une hiérarchie de dossier n'est qu'une projection d'un système multi-dimensionnel sur une dimension, donc qui peut le plus peut le moins.
une recherche puissante (qui se définira forcément sur certains axiomes)
Oui et alors ?
Imaginons un MUA avancé A, qui me permet de rechercher sur un prédicat P qui m'intéresse. La détermination de la valeur de ce prédicat pour un courriel donné implique la disponibilité d'un en-tête H absent de la RFC originelle. Et un MUA classique B ne permettant pas cette recherche.
Imaginons un courriel C disposant du dit en-tête et un D legacy qui ne l'a pas.
Avec A je peux trouver C et pas D. Avec B je ne trouve rien du tout puisque je ne peux pas chercher suivant P. Tu pourras rétorquer qu'il peut être trompeur de trouver un des deux résultats avec A (je peux me dire "ah bah il n'y a que C alors" et complètement passer à côté de D). Je répondrai avec une stat Zénitramienne et rétorquerai que je m'en fiche, à part les ML de barbus qui de toute façon ont pour vœu secret de tuer SMTP au profit d'un autre machin, tout le monde ajoute H à ses courriels.
Mais dans tout ces cas, il y a une prise de parti qui se fera forcément au détriment de d'autres possibilités des emails.
Non je ne vois pas pourquoi. Si, à la limite, si ton workflow est "j'ai absolument besoin de dossiers et surtout pas de tags" ; maintenant j'attends un exemple concret. Et si vraiment tu es dans ce cas-là, bah utilise pas mon MUA.
Et toutes ces possibilités de l'email ne sont que pas liées au MUA, ou encore au protocole ou même à l'environnement desktop qu'on utilise mais à l'email lui même en réalité.
Non. Même si une RFC plus stricte permettrait sans doute de faciliter les choses, rien ne t'empêche d'avoir un MUA ultra avancé qui répond à 99% des attentes de 98% des gens grâce à de puissantes heuristiques (hormis le temps, l'argent et les compétences évidemment). Le tout sans empêcher quoi que ce soit (tu peux par exemple très bien implémenter ta super recherche à base d'Elastic Search en y dénormalisant les données de tes courriels, permettant ainsi de les lire avec un MUA rustique à côté (et les courriels pourris du millénaire dernier ne remonteront pas sur des recherches structurées, uniquement en fuzzy ; et ?)).
Mais puisque le standard nous le permet, nous pourrions utiliser l'email d'une autre manière que la tienne et y trouver tout autant notre compte.
Tout à fait mais je ne vois toujours pas en quoi un MUA me satisfaisant t'en empêcherait. Et puis le sujet du journal étant "votre mutt là c'est de la marde et je veux gmail en libre" (je critique pas, j'ai à peu près la même position) je pense être plus en phase.
[^] # Re: Retour depuis le turfu
Posté par Sufflope (site web personnel) . En réponse au journal À la recherche des clients mail sous Linux. Évalué à 4.
On prend position sur "ce que mon MUA de 2016 arrivera à tirer de tes vieux mails" mais pas forcément "ce que tu seras encore en droit de faire avec ton logiciel qui te plait".
Parce qu'une hiérarchie de dossier n'est qu'une projection d'un système multi-dimensionnel sur une dimension, donc qui peut le plus peut le moins.
Oui et alors ?
Imaginons un MUA avancé A, qui me permet de rechercher sur un prédicat P qui m'intéresse. La détermination de la valeur de ce prédicat pour un courriel donné implique la disponibilité d'un en-tête H absent de la RFC originelle. Et un MUA classique B ne permettant pas cette recherche.
Imaginons un courriel C disposant du dit en-tête et un D legacy qui ne l'a pas.
Avec A je peux trouver C et pas D. Avec B je ne trouve rien du tout puisque je ne peux pas chercher suivant P. Tu pourras rétorquer qu'il peut être trompeur de trouver un des deux résultats avec A (je peux me dire "ah bah il n'y a que C alors" et complètement passer à côté de D). Je répondrai avec une stat Zénitramienne et rétorquerai que je m'en fiche, à part les ML de barbus qui de toute façon ont pour vœu secret de tuer SMTP au profit d'un autre machin, tout le monde ajoute H à ses courriels.
Non je ne vois pas pourquoi. Si, à la limite, si ton workflow est "j'ai absolument besoin de dossiers et surtout pas de tags" ; maintenant j'attends un exemple concret. Et si vraiment tu es dans ce cas-là, bah utilise pas mon MUA.
Non. Même si une RFC plus stricte permettrait sans doute de faciliter les choses, rien ne t'empêche d'avoir un MUA ultra avancé qui répond à 99% des attentes de 98% des gens grâce à de puissantes heuristiques (hormis le temps, l'argent et les compétences évidemment). Le tout sans empêcher quoi que ce soit (tu peux par exemple très bien implémenter ta super recherche à base d'Elastic Search en y dénormalisant les données de tes courriels, permettant ainsi de les lire avec un MUA rustique à côté (et les courriels pourris du millénaire dernier ne remonteront pas sur des recherches structurées, uniquement en fuzzy ; et ?)).
Tout à fait mais je ne vois toujours pas en quoi un MUA me satisfaisant t'en empêcherait. Et puis le sujet du journal étant "votre mutt là c'est de la marde et je veux gmail en libre" (je critique pas, j'ai à peu près la même position) je pense être plus en phase.