Bonsoir,
J'ai pensé a un concept d'application pour lire/envoyer des mails un peu particulier. Et j'aimerais ouvrir ce journal pour permettre de collecter des commentaires a son propos ... et pourquoi pas l'implémenter si cala n'existe pas déjà.
Le concept est relativement simple. Un mail est un fichier comme un autre ... pourquoi le différencier. Pourquoi le placer dans une application dont il ne sortira pas ?
Car on peut tout de même remarquer qu'on ne change pas facilement de lecteur de mails ... il faut configurer tout les comptes, déplacer son courrier sauvegardé, et configurer diverses autres choses.
Alors bien sûr, le concept un mail = un fichier est déja utilisé dans le format de boîte aux lettres de type maildir (malheureusement pas présent dans mozilla).
Mais ce que je verrais cerait une approche plus radicale. Ainsi pour une application maintenant, on pourrait en avoir deux:
- une application qui va chercher le courrier sur Internet et la place dans différents dossiers en fonction de certains filtres
- une application qui peut lire les fichiers ainsi créés. En créer de nouveaux et les envoyer.
Cette application serait en outre capable de lire les mails d'un dossier en particulier pour afficher rapidement le sujet ou un aperçu.
En fait, je m'en rend compte maintenant, il n'y a pas beaucoup de changement. Si ce n'est la flexibilité. Et on sortirait d'un concept de super-application qui fait tout à la fois pour devenir plus modulaire.
Qu'en pensez-vous ?
Cela existe-t-il déjà ?
Journal un concept de lecteur de mails particulier
16
oct.
2005
# IMAP, fetchmail et SMTP
Posté par SKBo . Évalué à 6.
- un démon fetchmail qui récupère les mails d'un peu partout pour un peu tout le monde ;
- un serveur SMTP qui récupère les mails en local et les dépose dans les bons répertoires suivant des règles que tu définies (règles sieve, classifieur bayésien...) ;
- un serveur IMAP qui permet d'accéder à tout cela quel que soit le client.
Ou alors j'ai rien compris, c'est tout à fait possible, il est tard :-p.
[^] # Re: IMAP, fetchmail et SMTP
Posté par Staz . Évalué à 6.
[^] # Re: IMAP, fetchmail et SMTP
Posté par Matthieu . Évalué à 7.
Il est donc parti du postulat que 1 mail = 1 fichier. Donc, il propose que les courriels soient stockés dans une arborescence de répertoire. Ainsi, il est facile à l'utilisateur de sauvegarder ses emails (il le pouvait avant oui, mais bon, c'est plus sûr dans le sens où dans 5 ans il pourra encore les lire), il peut également naviguer dans l'arborescence avec un explorateur de fichier, lire les messages avec un editeur de texte s'il le désire. Il peut même migrer d'un client de messagerie à un autre très facilement (sans faire d'import/export des messages).
Voila, il propose un système simple permettant d'avoir le contrôle total sur les messages stockés sur son PC. Je pense qu'il ne veut pas mettre en place de serveur, c'est bien pour les informaticiens, mais pour les utilisateurs c'est inconcevable.
Voila ce que j'ai compris. Ce n'est pas une mauvaise idée. Ca permettrait en plus de simplifier d'autres applications comme beagled par exemple qui pourrait traiter les messages comme des fichiers au lieu de devoir interpréter les formats de stockage...
[^] # Re: IMAP, fetchmail et SMTP
Posté par Benjamin (site web personnel) . Évalué à 2.
Je mets le postulat en échec : pourquoi stocker dans 1 fichier un mail constitué de 3 pièces jointes ? Pourquoi ne pas séparer les pièces jointes pour pouvoir justement les lires directement avec leur logiciel d'origine en cliquant dessus ?
Eudora (sous windows) procède ainsi : il stocke les mails dans des dossiers, (je ne sais plus si c'est un mail par fichier ou façon mbox) et crée des dossiers sur le disque dans lesquels il stocke les pièces jointes de ces mails. Ainsi, il suffit de cliquer sur un fichier attaché pour pouvoir l'ouvrir dans son logiciel associé.
Cela me parait donc plus pertinent.
Toutefois, une telle approche a son lot de problème :
- Le mail d'origine n'est pas conservé dans son intégralité
- La pièce jointe peut être modifiée si on la sauve dans son logiciel associé, on perd donc l'original dans ce cas
- Je ne pense pas que cela soit compatible avec Imap, et dans tous les cas, si la pièce jointe est modifiée, le message qui devrait être modifié localement ne sera pas réinjecté dans le serveur imap.
Donc on perd l'avantage de la synchro de ses données local/distant.
Cela me fait penser à quelque chose ... Je sens que cela va donner naissance à un autre journal ...
[^] # Re: IMAP, fetchmail et SMTP
Posté par Christophe Bliard . Évalué à 3.
Je préférerai avoir 1 conversation = 1 fichier ainsi on reporte la complexité du suivi d'un fil au moment de la collecte du mail (1 fois), et non plus au moment de la lecture (plusieurs fois).
On pourrait alors avoir un programme simple pour lire un fichier de mails, car il suffirait de lire qu'un seul fichier pour suivre toute une conversation.
[^] # Re: IMAP, fetchmail et SMTP
Posté par Anonyme . Évalué à 3.
On croirait pas, mais si la gestion des courriels est relativement complexe, c'est parce que les besoins le sont. Et il n'est pas évident de repartir de zéro en pensant pouvoir facilement gérer sa complexité.
J'ai l'impression que ça ne fait que condamner à réinventer le tout.
En bref, il s'agit d'inventer un nouveau format dont l'intérêt n'est pas évident...
[^] # Re: IMAP, fetchmail et SMTP
Posté par figus . Évalué à 3.
J'ouvre un message avec mon éditeur de texte. Et je me rends compte que j'ai envie d'y répondre. Ben je n'ai qu'à cliquer sur le bouton 'répondre'. Pas besoin de fermer l'éditeur de texte, d'ouvrir mon logiciel de mail habituel, de chercher le message en question et d'enfin cliquer sur le bouton 'répondre'.
Ca, c'est de l'intégration comme je l'aime.
En fait, aujourd'hui, s'il y a des clients mail, c'est parce qu'on a pas abstrait toute la partie transport des messages (nom du serveur, protocole, etc...). C'est un peu comme s'il fallait utiliser un logiciel dédié pour exploiter toutes les ressources réseau (non-locales au disque dur).
[^] # Re: IMAP, fetchmail et SMTP
Posté par Staz . Évalué à 3.
Ces formats indiquent juste comment sont arrangés les mails dans les fichiers, ceux-ci étant en eux-memes stoqués au format RFC 2822 (une variation du RFC 822 qui existait deja avant ma naissance). Il est donc facile de passer d'un format a l' autre.
Donc il n'y a guere de probleme de perenite des donnes. Le passage d'un client a l'autre se fait d'ailleurs assez facilement vu que la plupart des clients acceptent le formt mbox (et certains maildir).
Naviguer dans ses mails comme dans ses fichiers en soit n'est pas une mauvais idee mais le probleme c'est que tu ne peux plus voir facilement toutes les meta-donnees associes a ce courier (si le message a ete lu, quel est l'expediteur, le sujet etc..) toutes ces informations etant encodee (au format RFC 2822 mentionnes plus haut) dans le mails. Bien sur on pourrait deplacer ces informations dans les attributs meme du fichier, mais ca ne fairait que deplacer le probleme, il faudrait de toute-facon une explication externe pour les lires. Et pour les applications externes comme Beagle, ca ne simplifie rien du tout.
Pardon si l'explication est confuse, je suis pas un grand pédagogue en gros le message que j'essaye de faire passer c'est que le systeme de mail qui vous semble si obscure est en fait assez simple et similaire a ce que Milred souhaite, le fait de voir des mails comme des fichiers n'est enfait qu'une simple facon de representer les donnees.
ps : désolé pour les accents, ma breezy ne veux plus en faire.
# Bof bof
Posté par Sébastien Munch . Évalué à 3.
Un mail sur un serveur (donc accédé en IMAP) a donc ces avantages :
- lisible à partir de n'importe où (pas seulement un lecteur de mail en local)
- matériel plus fiable (entre un laptop Sony et un serveur IBM, hein...)
- sauvegarde sur bande (ou autre...)
Il y a certainement encore d'autres avantages, mais ceux-ci me suffisent largement !
Par contre, je ne vois pas d'avantage à avoir les mails en local, en tant que fichiers...
[^] # Encore une couche: Bof bof
Posté par Sébastien Munch . Évalué à 2.
Et pour les mails sauvegardés, tout reste dans les dossiers IMAP, donc rien à déplacer pour "changer" d'application.
Et puis l'IMAP permet aussi d'avoir un webmail, pour si jamais tu n'as pas d'accès à une application de mail "lourde".
=================
Et si vraiment tu veux pouvoir accéder aux mails comme à des fichiers à partir d'autres applications, je verrais plutot un méta-système de fichiers "imapfs" (style lufs) qui irait piocher les données *dans* les e-mails (ah bah oui, parce qu'un email en tant que tel, ce n'est pas très exploitable : headers du mail, headers MIME) : pour chaque mail, pouvoir accéder à chaque objet MIME, et lire le texte du mail comme du texte simple, ou comme du html si c'est un mail en html. Et voir les pièces jointes des mails comme des fichiers dans un filesystem, tout simplement... Enfin tout ça quoi...
[^] # trop de fichiers sur un fs normal ?
Posté par z a . Évalué à 1.
[^] # Re: trop de fichiers sur un fs normal ?
Posté par Mildred (site web personnel) . Évalué à 1.
Au pire, on peut tout mettre dans une archive tar ... mais il manque encore le translator tarfs ...
[^] # Re: Bof bof
Posté par Mildred (site web personnel) . Évalué à 3.
Les sauvegarder. Les avoir sous la main.
Personellement, j'utilise encore du vieux POP car je ne vois pas a quoi pourrait me servir l'IMAP ... car je sauvegarde TOUS mes e-mails depuis le début. Et la place que j'ai sur mon serveur de mails est limitée.
en plus je peux utiliser des outils pour rechercher dans le contenu des e-mails ... c'est peut être possible avec IMAP, mais je ne pense pas que soit aussi facile (il faut un cliuent compatible).
En local, il y a des tas d'applications pour rechercher du texte dans des fichiers.
Alors bien sûr, je peux mettre en place un serveur IMAP mais c'est un peu compliqué pour moi.
Et comment faire alors pour réinjecter tous les mails de Moz-Thunderbird (ou autre) dans ce serveur IMAP ?
[^] # Re: Bof bof
Posté par Staz . Évalué à 2.
Ce n'est guere un probleme avec l'IMAP, tu peux demander a ton client mail de conserver une copie en local afin de pouvoir consulter ton courrier sans connexions (et avoir un backup)
L'interet de l'IMAP c'est quand tu te retrouve souvent a utiliser des ordinateurs differents et que tu souhaite pouvoir consulter tes mails de n'importe ou, c'est egalement tres utile pour unifier plusieurs comptes mails. Note que je cherche pas a te forcer a utiliser IMAP, juste a t'informer de ses aventages/inconvegnant).
Utiliser IMAP sur un serveur mail ou l'espace est limite est en effet peu pratique, il vaut meme mieux l'utiliser sur un serveur qu'on controle soit meme (ou appartenant a une connaissance)
En fait il ne faut pas voir IMAP de la meme maniere que le compte mail que ton ISP te fourni mais plutot comme si tu partagais toi meme un dossier contenant les fichiers aux quels tu veux pouvoir acceder par tout (via un ftp par exemple)
La plupart des "gros" clients libres supportent l'imap : Thunderbird, Sylpheed, Evolution, Balsa, Kmail etc... Et ils le font de maniere transparente, comme si tes mails etaient stoqués en local sur ton disque dur (meme pour la recherche). D'ailleurs pour importer tes mails sur IMAP un simple glissé-desposé suffit.
# Système de fichier...
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
Mais c'est vrai, la tendance actuelle est de faire comme pour MacOsX ou Windows et mettre au chiotte les principes même d'Unix (un outil fait qu'une seule et unique chose et le fait bien, tout est fichier, etc.), juste pour faire plaisir aux nouveaux venus, pour surtout ne pas perturber leurs petites habitudes ... les pauvres petits.
[^] # Re: Système de fichier...
Posté par Ph Husson (site web personnel) . Évalué à 5.
Oui je sais tres leger tout ca :D
[^] # Re: Système de fichier...
Posté par Juke (site web personnel) . Évalué à 3.
[^] # Re: Système de fichier...
Posté par GTof . Évalué à 4.
[^] # Re: Système de fichier...
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Fini les gestionnaires de fichiers qui font tout ou des outils lourdaux pour des tâches simples. Ceci pourrait rendre les programmes plus petits et donc moins soumis aux bogues. De plus, ceci unifierait un tant soit peu l'accès et la manipulation des données.
Chaque programme serait dédié à une usage précis.
Reste à faire de même pour le système graphique : remplacer ce lourdaud de X par un environnement qui respecterait la philosophie d'Unix, sous forme par exemple de système de fichiers comme pour Plan9.
[^] # Re: Système de fichier...
Posté par Staz . Évalué à 0.
<_<
Juste pour te faire remarquer l'enormite de la connerie que tu as ecris dans ton commentaire (et informer les gens qui l'ont vote pertinent) :
Le systeme mail actuel existe depuis plus de DEUX DIZAINES d'années (la rfc du protocole POP date d'Octobre 84, ce qui lui donne 21 ans ce mois-ci)
Donc " [...] la tendance actuelle est de faire comme pour MacOsX ou Windows et mettre au chiotte les principes même d'Unix [...]" c'est vraiment n'importe quoi.
Mais tu peux tout a fait le faire, d'ailleur c'est quasi ce que je fais. Sauf que je suis soucieux de ma bande passante et de la vitesse d' execussion. Donc j'utilise IMAP qui n'est apres tout qu'une couche au dessus. (et qui se paye meme le luxe de gerer les problemes de lock etc..)
[^] # Re: Système de fichier...
Posté par Miguel Moquillon (site web personnel) . Évalué à 4.
Parce que les protocoles mail ont dans les 2 ans. Et alors ? Ils disent comment écrire des client ces protocoles ? Non. Rien n'empêche de les implémenter sous forme de système de fichier ... à la Unix.
La façon Windows ou MacOS est une façon orientée application et non document. Faire une chose ou plusieurs choses à la fois ne peut se faire que via une application bien particulière, avec ses qualités et ses défauts. Pour le cas du mail ou de la gestion de fichier avec les fichiers distants, c'est exactement ce que font les outils KDE ou GNOME par exemple, sous GNU/Linux ou *BSD. Donc oui, ils mettent en quelque sorte aux "chiottes" le principe d'Unix selon lequel tout est fichier, que cela ne te plaise ou non.
Dans l'esprit Unix, on manipule des documents ... pas des applications ; combien parmi les développeurs sous Unix l'ont compris ? Au vues des applications que l'on a à notre disposition, je dirais pas bcp. Et pourquoi ? Probablement parce que la majorité actuelle viennent d'environnement ou de formation dans lesquels tout est perçu sous forme d'applications. Ce qui n'enlève en rien le formidable travail qu'ils ont réalisés.
Bien sûr, il faut aussi relativiser et percevoir que dans les années 70 et 80, les techniques étaient relativement modestes pour pouvoir implémenter bcp de choses sous forme de fichiers, comme par exemple le système graphique (cf. X11). C'est pourquoi ce n'est qu'à partir des années 90 que Plan9 a vue le jour.
Aujourd'hui on a les techniques de suivre la philosophie Unix jusqu'au bout, et donc de proposer une approche complètement différentes de celles de Windows ou de MacOSX et AMHA ce n'est pas plus mal.
[^] # Re: Système de fichier...
Posté par Staz . Évalué à 2.
Juste pour information. la philosophie d'Unix c'est "tout est fichier" PAS "tout est systeme de fichier".
Unix, n'a jamais preconise d'utiliser un systeme de fichier par utilisateur et encore moins pour chaque utilisation dont ils auraient besoin. D'ailleurs dans les contextes d'utilisation d'unix en terminal/serveur ca semble plutot absurde, suffit d'imaginer la gueule qu'aurait le fstab d'une universite de 30 000 etudiants
Quand je dis que le system mail utilise de nos jours a plus de 20 ans, ca comprenais egalement le stockage. Bon je vais illustrer un peu pour rendre plus clair:
Sous unix quand c'etait le bon temps :
Ton application mail sauvais tes mails dans le fichier ~/mbox au format mbox.
De nos jour avec les jeunes qui respectent plus rien :
Ton application mail sauve tes mails dans ~/.thunderbird/mail (ou un truc dans le genre) au format mboxrd (qui est une variation de mbox)
Je t'avoue que je vois mal ou l'esprit d'unix a ete corrompu la.
La difference c'est que tu as une joli interface pour faire clic clic dessus. C'est pas parce que c'est cache que ca existe plus !
Tu parle de GnomeVFS et de l'equivalent sous KDE? La je suis assez d'accord mais c'est un tout autre debat.
De meme que je n'aime pas non plus que toutes les applications deviennent des bloatwares ou l'on se retrouve enferme (Evolution par exemple meme si je l'aime beaucoup)
La je t'avoue que ca m'interesse dans savoir vachement plus. :) J'ai du mal a imaginer un systeme graphique sous forme de fichiers et les aventages que ca pourrait apporter, surement parce que je n'ai pas connu plan 9. Donc vas y explique, je lirai avec attention et interet.
note : desole pour les accents
[^] # Re: Système de fichier...
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Sinon, pour Plan9 et son système graphique :
http://www.cs.bell-labs.com/sys/doc/8½/8½.html
# Let it be
Posté par Larry Cow . Évalué à 3.
Dans l'ensemble, et si j'ai bien compris: oui.
En gros, tu viens de décrire l'architecture de gestion du courrier de BeOS (via le MailKit).
[^] # Re: Let it be
Posté par jaroug (site web personnel) . Évalué à 3.
[^] # Re: Let it be
Posté par Mildred (site web personnel) . Évalué à 1.
En ce moment, j'utilise Thunderbird mais je trouve qu'une application entièrement gecko est un peu lourde sur mon système (pourtant pas une petite config, date juste de 3 ans) ...
Un truc bien intégré à Gnome de préférence (Gtk2) et avec possibilité d'import depuis Thunderbird ...
Merci
[^] # Re: Let it be
Posté par jaroug (site web personnel) . Évalué à 2.
C'est du gtk2, donc c'est cool et puis c'est léger. De plus les emails sont proprement sotckés (pas comme l'organisation bordélique de Thunderbird).
J'ai seulement pas réussi à importer mon carnet d'adresse que j'avais exporter au format ldif. Sylpheed-claws reconnait pourtant théoriquement ce format.
[^] # Re: Let it be
Posté par Mildred (site web personnel) . Évalué à 1.
Et je préfère Sylpheed à Sylpheed-claws GTK2 ...
Pour commencer, les icones sont plus jolies .. Et il y a aussi les titres des colonnes qui sont bizarres avec mon theme (Smokey-Blue juste pour les widgets) ...
Maos a part ca, c'est vrai que Sylpheed-claws a vraiment des fonctionnalités intéressantes ...
[^] # Re: Let it be
Posté par Sylvain Sauvage . Évalué à 2.
Perso, je crois que la seule raison qui me fait utiliser « claws » plutôt que « vanilla », c'est la présentation en boutons des parties d'un message (des petits boutons à droite du message : enveloppe, corps (text ou html), pièces attachées...). Sylpheed ne propose que la présentation en liste qui prend trop de place verticale pour être utile.
[^] # Re: Let it be
Posté par Mildred (site web personnel) . Évalué à 1.
Sinon, c'est vrai que l'affichage par la droite est très pratique, je trouve.
Au fait, est-il possible de migrer facilement entre vanilla et claws ? Les mails c'est presque automatique ... mais je parle des comptes, address-book ... ?
Sinon, pour importer mes mbox de Thunderbird, il y a une entrée dans le menu fichiers.
Et a partir de Gnome 1.12, on peut modifier les raccourcis claviers directement. Du coup, c'est très rapide.
J'ai posté une astuce à ce propos. En gros, il faut aller dans Préférences -> Menus & Barres d'outils -> cocher « Raccourcis claviers éditables ».
Dans une application, dérouler un menu, mettre sa souris sur une entrée (sans cliquer), taper sur le clavier et le raccourci apparaît à droite.
[^] # Re: Let it be
Posté par Sylvain Sauvage . Évalué à 2.
Les comptes et adresses passent tout seuls.
Il n'y a que pour les règles de filtrage que ça pourrait coincer, et encore, je crois qu'il y a maintenant des outils, voir sur le site. Pour mon premier test de claws, j'ai simplement créé une règle, repéré le fichier modifié et son format (c'est du texte), puis un coup de awk pour transformer celui de sylpheed pour que claws l'utilise.
Je reteste sylpheed de temps en temps pour voir si j'abandonne claws. (Bon, en fait, j'ai déjà abandonné claws puisque j'utilise claws-gtk2 ;oP )
# MH, Maildir...
Posté par Sylvain Sauvage . Évalué à 5.
En ce qui concerne l'idée de mettre un message par fichier, comme certains commentaires l'ont déjà dit, c'est déjà le cas des formats MH et Maildir p.ex.
Le format d'un fichier est celui de la RFC 822.
N'importe quel éditeur de texte peut le lire et des outils (comme recode) permettent d'en extraire les données binaires.
En ce qui concerne séparer la réception de la lecture en deux programmes différents, l'intérêt est plutôt limité.
Prenons un client de messagerie.
1. Son activité principale est de lire les messages archivés.
2. Il a aussi un (petit) module qui permet de récupérer les messages (avec des sous-modules pour les différents protocoles pop, imap, pop-ssl, etc.).
3. Il a aussi des modules-filtres simples qui lui permettent de classer les messages ou d'utiliser des filtres externes pour le faire.
4. Et, enfin, il a un petit module pour éditer un nouveau message et pour l'envoyer suivant le protocole SMTP.
Si j'ai bien compris, ce que tu proposes, c'est de séparer ces activités pour ne pas avoir de bloatware.
Or, en fait, les clients de messagerie bien faits sont déjà modularisés pour ces activités. Le fait que les modules soient présentés dans un seul programme est juste une facilité pour l'utilisateur.
Évidemment, il y a toujours une tendance à ajouter une petite fonctionnalité par ci, une petite fonctionnalité par là. Il y a aussi le fait que le programme commence par fournir un module minimal pour une fonctionnalité (p.ex. l'édition) puis ce module grossit et commence à « en faire trop ». Mais beaucoup de clients ont pour but de rester simples et modulaires (sylpheed, mutt, balsa...).
Effectivement, il y a des programmes qui sont dès le début mal conçus et qui commencent comme un bloat avant même d'être utilisés.
Il y a aussi certaines difficultés à passer d'un programme à un autre, mais il s'agit surtout du transfert de données de petite taille qui n'ont pas de format standard (qu'est-ce qu'un compte, une règle de filtrage...). Il y a rarement des problèmes avec les messages eux-mêmes¹.
¹ : en tout cas pour les logiciels que j'ai côtoyés/utilisés (netscape, mozilla, sylpheeds, kmail, emacs...).
# Redécouvrons Unix
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 2.
En gros, le principe de réception est le suivant :
- le courrier est véhiculé entre machine par des MTA (Mail Transfert Agent : http://fr.wikipedia.org/wiki/Mail_Transfer_Agent ),
- une fois recut, le courrier est distribué par un MDA (Mail Delivery Agent : procmail je crois, que l'on peut configurer pour classer le mail dès réception avec le .procmailrc)
- le courrier est lu et édité par un MUA (Mail User Agent : http://fr.wikipedia.org/wiki/Client_email , le plus trivial étant mailx).
Comme dit plus haut, dans les architectures centralisée, comme le courrier n'est pas expédié sur VOTRE machine (bienqu'avec l'ADSL et les IP fixes cela devienne possible), pour alimenter le MDA il faut utiliser un programme du genre fetchmail. Sous Debian il existe un fetchmaild très pratique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.