Puisque Thunderbird est à l'honneur à l'occasion de la création de la nouvelle filiale Mozilla Messenging, je me permet de vous faire part d'une petite réflexion à ce sujet...
AMHA l'adoption "massive" de Thunderbird passe par l'intégration de fonctionnalités que les autres n'ont pas. C'est ce qui a fait le succès de Firefox et je ne vois pas pourquoi ça ne marcherait pas pour Thunderbird.
A ce propos, il y a une fonctionnalité que je n'ai vue nulle part (mais je suis loin de connaitre tous les clients de mail) et que j'aimerais beaucoup voir dans Thunderbird : c'est la possibilité de stocker ses mails dans différents fichiers situés dans différents répertoires.
Je m'explique.
Quand on conserve beaucoup de mails, on peut créer des "dossiers" dans sa boite de réception pour organiser un peu tout ça. Super. Mais à la longue ces dossiers constituent une sorte "d'arborescence parallèle" qui fait quasiment doublon avec l'arborescence du système de fichier. D'où ma question : pourquoi ne pas stocker directement ces mails dans l'arborescence du système de fichier ? En pratique, ils pourraient par exemple être stockés dans des sous-répertoires cachés ".Mail"
Comme ça, je pourrais stocker les mails que je reçois de ma banque dans mon dossier "Comptes" (avec mes feuilles de comptes OpenCalc) et les mails que je reçois de ma copine Lulu dans le dossier "Lulu" avec les photos de nos dernières vacances. C'est comme ça que je fais pour le courrier postal (je ne garde pas toutes les lettres que je conserve au même endroit) et je ne vois pas pourquoi il devrait en être différemment pour mon courrier électronique.
Outre la satisfaction d'une organisation rationnelle, cela permettrait par exemple de faciliter les sauvegardes (quand je fais une sauvegarde de mes comptes, je sauvegarde en même temps tous les mails de ma banque). Accessoirement, cela permettrait aussi d'éviter à mes collègues de m'appeler au secours quand leur boite mail atteint les 2 Go et que le système de fichiers vétuste de leur OS non moins vétuste dépose les armes (la valeur de 2 Go est donnée de mémoire, c'est peut-être un peu plus).
De plus, cela ne me parait pas techniquement insurmontable (bien que je sois totalement incapable de le faire à ma grande honte). Bien sûr, il faudrait déconnecter la gestion des comptes du stockage et garder aussi une boite à lettre "par défaut" où arrivent tous les mails d'un compte donné, mais à partir de là de multiples possibilités sont ouvertes. A terme, on peut même envisager un client de mail qui soit capable d'ouvrir un dossier de mails dans un répertoire quelconque comme un traitement de texte ouvre une lettre.
En fait je suis un peu étonné qu'aucun client mail (à ma connaissance en tout cas) n'ait encore envisagé la chose. Suis-je le seul à trouver cela intéressant ?
Je serais heureux d'avoir vos commentaires à ce sujet.
Bien à vous et toute cette sorte de choses...
Journal Thunderbird (Encore !)
20
fév.
2008
# Maildir
Posté par MrLapinot (site web personnel) . Évalué à 5.
Bon, j'exagère un peu, la solution que tu suggères est légèrement plus élaborée, mais on n'en est pas loin. Il suffit d'avoir plusieurs boîtes Maildir, une dans chaque dossier qui t'intéresse en fait (par exemple ton dossier Comptes contiendra 3 répertoires, cur, new et temp, qui stockeront tes mails liés à la banque). Reste à trouver un logiciel qui fait du multicomptes et gère le format Maildir, c'est pas bien dur (mais un peu lourd, ça impose de créer un "compte" mail par dossier).
[^] # Re: Maildir
Posté par Psychofox (Mastodon) . Évalué à -7.
NAME
maildir - directory for incoming mail messages
INTRODUCTION
maildir is a structure for directories of incoming mail mes-
sages. It solves the reliability problems that plague mbox
files and mh folders.
RELIABILITY ISSUES
A machine may crash while it is delivering a message. For
both mbox files and mh folders this means that the message
will be silently truncated. Even worse: for mbox format, if
the message is truncated in the middle of a line, it will be
silently joined to the next message. The mail transport
agent will try again later to deliver the message, but it is
unacceptable that a corrupted message should show up at all.
In maildir, every message is guaranteed complete upon
delivery.
A machine may have two programs simultaneously delivering
mail to the same user. The mbox and mh formats require the
programs to update a single central file. If the programs
do not use some locking mechanism, the central file will be
corrupted. There are several mbox and mh locking mechan-
isms, none of which work portably and reliably. In con-
trast, in maildir, no locks are ever necessary. Different
delivery processes never touch the same file.
A user may try to delete messages from his mailbox at the
same moment that the machine delivers a new message. For
mbox and mh formats, the user's mail-reading program must
know what locking mechanism the mail-delivery programs use.
In contrast, in maildir, any delivered message can be safely
updated or deleted by a mail-reading program.
Many sites use Sun's Network Failure System (NFS), presum-
ably because the operating system vendor does not offer any-
thing else. NFS exacerbates all of the above problems.
Some NFS implementations don't provide any reliable locking
mechanism. With mbox and mh formats, if two machines
deliver mail to the same user, or if a user reads mail any-
where except the delivery machine, the user's mail is at
risk. maildir works without trouble over NFS.
THE MAILDIR STRUCTURE
A directory in maildir format has three subdirectories, all
on the same filesystem: tmp, new, and cur.
Each file in new is a newly delivered mail message. The
modification time of the file is the delivery date of the
message. The message is delivered without an extra UUCP-
style From_ line, without any >From quoting, and without an
SunOS 5.5 Last change: 1
maildir(5) Headers, Tables, and Macros maildir(5)
extra blank line at the end. The message is normally in RFC
822 format, starting with a Return-Path line and a
Delivered-To line, but it could contain arbitrary binary
data. It might not even end with a newline.
Files in cur are just like files in new. The big difference
is that files in cur are no longer new mail: they have been
seen by the user's mail-reading program.
HOW A MESSAGE IS DELIVERED
The tmp directory is used to ensure reliable delivery, as
discussed here.
A program delivers a mail message in six steps. First, it
chdir()s to the maildir directory. Second, it stat()s the
name tmp/time.pid.host, where time is the number of seconds
since the beginning of 1970 GMT, pid is the program's pro-
cess ID, and host is the host name. Third, if stat()
returned anything other than ENOENT, the program sleeps for
two seconds, updates time, and tries the stat() again, a
limited number of times. Fourth, the program creates
tmp/time.pid.host. Fifth, the program NFS-writes the mes-
sage to the file. Sixth, the program link()s the file to
new/time.pid.host. At that instant the message has been
successfully delivered.
The delivery program is required to start a 24-hour timer
before creating tmp/time.pid.host, and to abort the delivery
if the timer expires. Upon error, timeout, or normal com-
pletion, the delivery program may attempt to unlink()
tmp/time.pid.host.
NFS-writing means (1) as usual, checking the number of bytes
returned from each write() call; (2) calling fsync() and
checking its return value; (3) calling close() and checking
its return value. (Standard NFS implementations handle
fsync() incorrectly but make up for it by abusing close().)
HOW A MESSAGE IS READ
A mail reader operates as follows.
It looks through the new directory for new messages. Say
there is a new message, new/unique. The reader may freely
display the contents of new/unique, delete new/unique, or
rename new/unique as cur/unique:info. See
http://pobox.com/~djb/maildir.html for the meaning of info.
The reader is also expected to look through the tmp direc-
tory and to clean up any old files found there. A file in
tmp may be safely removed if it has not been accessed in 36
hours.
SunOS 5.5 Last change: 2
maildir(5) Headers, Tables, and Macros maildir(5)
It is a good idea for readers to skip all filenames in new
and cur starting with a dot. Other than this, readers
should not attempt to parse filenames.
ENVIRONMENT VARIABLES
Mail readers supporting maildir use the MAILDIR environment
variable as the name of the user's primary mail directory.
SEE ALSO
mbox(5), qmail-local(8)
SunOS 5.5 Last change: 3
[^] # Re: Maildir
Posté par phyce . Évalué à 4.
Bon OK c'est pas très facile à mettre en place mais pour tes sauvegardes séparées ca me parait convenir, non ?
[^] # Re: Maildir
Posté par TemPi . Évalué à 3.
[^] # Re: Maildir
Posté par tuXico . Évalué à 4.
[^] # Re: Maildir
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
:-)
(trés trés vieux bugs :-)
[^] # Re: Maildir
Posté par jMax . Évalué à 2.
>Tu viens de réinventer Maildir, félicitations !
Merci mais autant que je sache maildir n'est pas fait du tout pour ça, mais plutôt pour éviter les locks sur les fichiers de mail.
D'autant que, comme tu le dis toi-même, la solution que tu proposes impose de créer un compte pour chaque répertoire... Pas très pratique voire même carrément rédhibitoire dès lors que tu as un nombre conséquent de répertoires.
De plus la solution me paraît peu évolutive. Le fait de déconnecter la partie gestion des comptes du MUA de sa partie stockage me parait présenter de nombreux avantages en termes de possibilités d'extension d'un client de Mail. En particulier permettre de voir le client de mail comme un gestionnaire de mail capable de gérer les mails où qu'ils se trouvent sur le disque, un peu à la manière de ce qu'on est en droit d'attendre d'un gestionnaire de photos. Une fonctionnalité un peu similaire (la possibilité d'avoir plusieurs album library path) est d'ailleurs parmi les plus demandées dans Digikam.
Donc, encore une fois comme tu le dis toi-même, je crois que tu exagères **un peu**.
# Depuis longtemps
Posté par Jeanuel (site web personnel) . Évalué à 3.
# Peut-être Akonadi ?
Posté par windu.2b . Évalué à 3.
Car (je cite) :
"Akonadi est le nouveau framework de gestion des données personnelles (PIM : Personal Information Management) de KDE 4. Il fonctionne comme un système de stockage de données extensible et accessible par toutes les applications PIM.
Akonadi garantit aussi l'unicité des données, évitant ainsi les doublons (en mémoire ou sur le disque) en cas d'accès simultané par deux applications PIM.
Enfin, c'est Akonadi (et non plus l'application le demandant) qui se charge de l'envoi et de la réception de données distantes. Ceci permet aux applications de ne plus avoir à gérer les protocoles.
"
Donc si Akonadi peut faire une telle chose, le problème est immédiatement "résolu" pour tous les logiciels reposant sur lui, non ? D'autant qu'Akonadi ne se veut pas limité à KDE, comme le montre l'image[2]
Bref, faudrait peut-être leur en toucher un mot, voire le proposer sur bugs.kde.org
1 http://www.pcinpact.com/d-115-6-kde4-nouveautes.htm (page 6)
2 http://static.pcinpact.com/images/bd/news/52277.png
# Mon opinion
Posté par Bozo_le_clown . Évalué à 6.
Tu te retrouves toujours dans le cas où tu ne sais pas placer un mail parce que tu voudrais le placer dans 2 catégories en même temps
Autant utiliser des tags et rechercher par tag.
Tout utilisateur de gmail te le dira
[^] # Re: Mon opinion
Posté par MrBidon . Évalué à 3.
Pourquoi n'ont - il pas couplé les deux ?
[^] # Re: Mon opinion
Posté par Bozo_le_clown . Évalué à 2.
ce qu'il faut c'est une hiérarchie dynamique.
Tu poses des tags comme tu as envie mais lorsque tu fais une recherche tu indiques un tag.
L'interface te propose tous les mails qui correspondent au tag et tous les tags discriminants (appliqué à la liste de mail) qui permettent d'affiner ta recherche ainsi ta hiérarchie se constitue dynamiquement à chaque recherche
C'est le principe utilisé pur del.icio.us et en mieux sur Simpy.
Je crois que c'est ce qui prévu avec les bookmarks sur FF3 mais je n'ai pas encore testé.
[^] # Re: Mon opinion
Posté par jMax . Évalué à 1.
>Tout utilisateur de gmail te le dira
Non.
Étant moi-même utilisateur de GMail, lorsque je m'interroge, je me répond à l'unanimité que dans ce cas précis, je préfère un classement hiérarchique. Donc non, **tous** les utilisateur de GMail ne sont pas forcément de cet avis.
Ceci étant, c'est vrai que ça fait pas très Web 2.0... mais pour être tout à fait honnête, moi, que ça fasse Web 2.0 ou pas, je m'en bat l'œil et plutôt deux fois qu'une. Moi ce qui m'intéresse c'est pas les concepts marketing plus ou moins fumeux, c'est que ça réponde à mon besoin. Et en l'occurrence, je suis certain que mon besoin, c'est un classement hiérarchique... (car depuis plusieurs années où j'utilise des sous-dossiers pour archiver mes mails, je ne me suis **jamais** retrouvé dans le cas où je voulais placer un mail dans deux catégories). Ceci étant tu es en droit d'avoir des besoins différents des miens et c'est un peu pour ça que j'ai écrit ce journal : pour voir si j'étais le seul à voir les choses de cette manière. En cela, tu as répondu à mon interrogation et je t'en remercie.
Plus généralement, je ne suis pas sûr que les tags soient la panacée. De fait, comme le sous-entends ton post, les tags, c'est bien pour faire des recherches, mais en termes d'organisation, je ne pense pas qu'on ait encore trouvé mieux que le classement hiérarchique.
Bien sûr, tout ceci n'engage que moi etc.
# Adoption massive ???
Posté par Zorro (site web personnel) . Évalué à 6.
Dans le cadre d'une utilisation personnelle, c'est un truc de vieux, d'ancienne génération.
Tous, je dis TOUS les internautes de moins de 25 ans que je connais, utilisent des webmails, et ne comprennent même pas l'utilité de s'encombrer avec des clients installés. La plupart n'ont même JAMAIS configuré leur compte dans Outlook ou Thunderbird.
Les seuls cas où les clients lourds c'est encore valable, c'est pour le travail professionnel car les clients installés restent encore pour le moment plus rapides et plus réactifs que les webmails. Mais ce n'est qu'une question de temps avant que là aussi les entreprises ne basculent définitivement vers les webmails.
C'est ce qu'à bien compris la Fondation Mozilla en se débarrassant de cet encombrant boulet du passé.
[^] # Re: Adoption massive ???
Posté par Nicolas Schoonbroodt . Évalué à 5.
[^] # Re: Adoption massive ???
Posté par windu.2b . Évalué à 5.
PS : bon anniversaire :-)
[^] # Re: Adoption massive ???
Posté par alexissoft . Évalué à 2.
[^] # Re: Adoption massive ???
Posté par thedidouille . Évalué à 1.
[^] # Re: Adoption massive ???
Posté par Zorro (site web personnel) . Évalué à 2.
Mais malheureusement, on n'est pas (encore) la majorité...
[^] # Re: Adoption massive ???
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Adoption massive ???
Posté par Maclag . Évalué à 2.
Si on peut avoir des services imap par exemple, et si TB propose des "plus".
Le genre de "plus", ce serait (par exemple) une interface avec la messagerie instantanée (après tout les webmails font bien ça, mais uniquement en circuit fermé: yahoo permet de savoir si les contacts yahoo sont connectés sur yahoo msgr, etc.).
Pour moi la solution, c'est plutôt un système de gestion de contacts élaborés, avec un client mail qui voit si le contact est connecté, même s'il n'utilise pas les mêmes comptes pour sa messagerie en ligne et son adresse mail, voire où il est connecté (genre "connecté sur le skype du boulot", "connecté sur compte jabber privé machin", etc.)
Mais là ça sort complètement du cadre du client mail isolé, faut une belle usine à gaz ou une déferlante d'outils bien intégrés.
En fait, il faut que TB se mette à Telepathy... :D
[^] # Re: Adoption massive ???
Posté par windu.2b . Évalué à 4.
KMail, Kopete, Konversation, KAddressBook... sont reliés et ainsi on sait qui est en ligne.
Et KDE 4.1 devrait encore améliorer tout ça
[^] # Re: Adoption massive ???
Posté par zebra3 . Évalué à 2.
Mais je trouve que c'est une bonne idée, d'ailleurs j'avais fait des recherches pour avoir même chose sous Opera, ce qui m'aurait permis d'avoir une seule appli pour tout ce qui est réseau/internet (web, mail, bittorrent, XMPP, ...).
Et pis vue la qualité d'Opera, c'est la preuve que ce genre de concept ne donne pas forcément une usine à gaz. Tout le monde ne s'appelle pas Microsoft, Mozilla ou OpenOffice.org !
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Adoption massive ???
Posté par Maclag . Évalué à 2.
Mais l'idée ici est bien de proposer des solutions en clients local et non en webmail (enfin web-tout en l'occurrence...)
Et je voudrais pousser le concept plus loin encore: Gmail, ça veut dire ton adresse Gmail, ton compte jabber Gmail etc.
Moi j'aimerais un client mail simple, mais qui communique avec un gestionnaire de contacts avancé (plusieurs comptes propres à moi, liste de contacts suivant les comptes, plusieurs comptes pour le même contact avec les préférences, enfin le gestionnaire de contact ultime quoi!)
Le client mail peut donc communiquer avec le gestionnaire de contacts, juste pour signaler les statuts des contacts, et donc sur option proposer le lancement du client im associé au contact, et décidé par le gestionnaire de contacts (si msn, lancer amsn, si jabber, gajim, suivant les désidérata les plus tordus de l'utilisateur!)
L'approche d'opera est intéressante, mais je préfère garder une séparation (un logiciel, une fonction, unix quoi!). Le principal c'est que tout ça communique et soit compatible!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.