Journal Thunderbird (Encore !)

Posté par  .
Étiquettes :
0
20
fév.
2008
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...
  • # Maildir

    Posté par  (site web personnel) . Évalué à 5.

    Tu viens de réinventer Maildir, félicitations !

    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  (Mastodon) . Évalué à -7.

      maildir(5) Headers, Tables, and Macros maildir(5)



      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  . Évalué à 4.

      Je suppose que tu dois pouvoir utiliser le format natif de TB, et faire des liens symboliques depuis le localfolder de TB ~/.Mail/Banque/Inbox vers ton ~/Banque/Courrier/Inbox par exemple.

      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  . Évalué à 3.

        C'est ce que je fait chez moi, et ça marche bien.
      • [^] # Re: Maildir

        Posté par  . Évalué à 4.

        Faire des liens me semble le plus pratique sinon Tu peux toujours faire un petit script de backup de Tes comptes qui prend en compte d'importer Tes mails avant le backup proprement dit.
    • [^] # Re: Maildir

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Pour le support de maildir, votez ! https://bugzilla.mozilla.org/show_bug.cgi?id=58308

      :-)

      (trés trés vieux bugs :-)
    • [^] # Re: Maildir

      Posté par  . É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  (site web personnel) . Évalué à 3.

    Je dois dire que j'attends cette fonctionnalité depuis longtemps. Mais j'en ai fait mon deuil. Ce n'est pas grand public. Le grand public laisse tous ses emails dans incomming....
  • # Peut-être Akonadi ?

    Posté par  . Évalué à 3.

    Je me demande si en:Akonadi (un framework de KDE 4[1], toujours en cours de développement mais devrait apparaître avec KDE 4.1) ne pourrait pas faciliter une telle chose ?
    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  . Évalué à 6.

    Les classements hiérarchiques c'est "has-been".

    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  . Évalué à 3.

      J'aime bien le principe des tag, mais au bout de 100 tags différents on se dis que se serait bien une petite hiérarchie en plus...

      Pourquoi n'ont - il pas couplé les deux ?
      • [^] # Re: Mon opinion

        Posté par  . Évalué à 2.

        Ce n'est pas incompatible mais
        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  . É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  (site web personnel) . Évalué à 6.

    Il n'y aura pas, plus jamais, d'adoption massive pour les clients mails à installer en local.
    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  . Évalué à 5.

      J'ai 24 ans (depuis aujourd'hui) et je n'utilises pas de webmail, mais kmail... Dommage pour tes stats /o\
      • [^] # Re: Adoption massive ???

        Posté par  . Évalué à 5.

        Pareil : 23 ans, j'utilise KMail, et avant ça TB \o/



        PS : bon anniversaire :-)
        • [^] # Re: Adoption massive ???

          Posté par  . Évalué à 2.

          Bravo, TB !
        • [^] # Re: Adoption massive ???

          Posté par  . Évalué à 1.

          putain, j'ai déjà 33 ans, mais j'utilise aussi Kmail.
        • [^] # Re: Adoption massive ???

          Posté par  (site web personnel) . Évalué à 2.

          Forcément, parmi les Linuxiens, on est trop fiers d'utiliser nos programmes locaux à nous !
          Mais malheureusement, on n'est pas (encore) la majorité...
        • [^] # Re: Adoption massive ???

          Posté par  . Évalué à 2.

          Bah moi aussi j'ai 24 ans, mais j'utilise Evolution

          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  . Évalué à 2.

      Pas si sûr!
      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  . Évalué à 4.

        Pour ça, y a Kontact qui le propose déjà.
        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  . Évalué à 2.

        Ben Gmail le fait non ? Et comme c'est XMPP, ben tu vois aussi tes contacts qui n'utilisent pas Gmail.

        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  . Évalué à 2.

          Tout à fait, Gmail le fait (enfin à ma connaissance, perso je n'utilise pas :P)
          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.