Journal Maildir, Mbox et autres

• # Ou sinon tu as Beagle, Strigi ...

  Posté par yannig (site web personnel) le 05 juillet 2007 à 09:17. Évalué à -1.

  

  Qui font la même chose en plus rapide et plus efficace.
  
  Et si tu veux pas d'interface graphique, il y'a même possibilité de faire fonctionner tout ça en ligne de commande.

  • [^] # Re: Ou sinon tu as Beagle, Strigi ...

    Posté par inico (site web personnel) le 05 juillet 2007 à 09:19. Évalué à 9.

    

    
    - les pieces jointes désencodées prennent moins de place que leur equivalent encodé
    - on pourrait avec un systeme de hash ( nom piece jointe, taille, md5 etc ) ne pas sauvegarder des pieces jointes identiques ( vous savez tout les mails que ce client vous envoie avec un fichier signature bmp identique à chaque fois. Et bien sur, vous devez garder le mail ... )

    
    
    Les logiciels d'indexion ne font pas çà.

• # git

  Posté par ribwund le 05 juillet 2007 à 09:48. Évalué à 3.

  

  
  on pourrait avec un systeme de hash ( nom piece jointe, taille, md5 etc ) ne pas sauvegarder des pieces jointes identiques ( vous savez tout les mails que ce client vous envoie avec un fichier signature bmp identique à chaque fois. Et bien sur, vous devez garder le mail ... )
  
  
  Ca ressemble au systeme de git ca :)

• # Mail.app fait comme ca

  Posté par Anonyme le 05 juillet 2007 à 11:04. Évalué à 3.

  

  Tu viens juste de réinventer le comportement de Mail.app sous Mac OS X. C'est effectivement assez pratique, évite une reconstruction a la main d'un fichier mailbox corompu (vécu), et globalement je pense que c'est geekproof (non pas que ca lui résiste, hein, mais plutôt que ca lui convient).
  
  Beaucoup disent qu'apple a abandonné mbox pour l'arrivée de l'indexation spotlight, qui a comme granularité le fichier.
  
  En tout cas il faudra trouver un moyen de contenter les esprits chagrin (mbox est pratique car reconnu par beaucoup d'application), mais le concept un email -> fichier + fichiers attachés a part mais référencés dans l'email me plait bien. Par contre halte aux hash : il est plus simple de suffixer le fichier avec une numérotation en cas de doublons, mais il faut absolument garder le nom original pour le nom de fichier sur le disque dur, pour pouvoir simplement retrouver ses fichiers sans passer par ton client mail (ou récupérer une catastrophe).

  • [^] # Re: Mail.app fait comme ca

    Posté par aedrin le 05 juillet 2007 à 11:56. Évalué à 1.

    

    et pourquoi pas "hash_de_taille_fixe-nom_du_fichier_original" ce qui permet d'avoir les deux informations efficacement à la fois pour un humain et pour un programme ?

    • [^] # Re: Mail.app fait comme ca

      Posté par Anonyme le 05 juillet 2007 à 13:57. Évalué à 2.

      

      Et bien entre nous, oui ca passerait, hors le tri alphabétique en vrac, mais le souci c'est que c'est pas Mme Michu proof - elle va se demander ce que c'est tous ces chiffres et du coup avoir peur de double cliquer dessus.

      • [^] # Re: Mail.app fait comme ca

        Posté par aedrin le 05 juillet 2007 à 19:14. Évalué à 1.

        

        entre nous Mme michu elle est pas sensée accéder très souvent à sa base de mail sous forme maildir ou autre, non ?
        en général, elle ne passe que par l'interface de son client mail pour accéder à ses mails...
        
        et puis le jour où ça casse, elle trouvera bien un geek pour lui faire un grep bien placé si besoin ! (d'ailleurs le grep non plus n'est pas très michu-compliant ;-)
        
        sinon, pour le tri alphabétique, on peut toujours mettre dans cet ordre "nom-hash"

  • [^] # Re: Mail.app fait comme ca

    Posté par sobek le 05 juillet 2007 à 20:01. Évalué à 2.

    

    C'est aussi et surtout ce que fait Eudora depuis de nombreuses années (encore une idée pompée par Apple et présentée comme une innovation, tient).
    
    Et pour le coup, en entreprise... C'est la merde !!!
    
    Plus sérieusement, le problème avec le fait d'utiliser les noms des pièces jointes, c'est que l'on ne maitrise pas les caractères utilisés. Et entre Linux qui est utf8 par défaut mais pas toutes les applis, MacOS X qui l'est à la va comme je te pousse, les autres unix qui ne le sont pas par défaut et surtout Windows qui utilise son propre système de codage, ça devient un de ces bordels lorsqu'il faut passer un utilisateur d'un système à un autre...
    
    Sans compter qu'il faut gérer le cas ou la pièce jointe a été supprimée soit suite à un problème de nommage (genre le caractère mal échapé qui ne peut être relu, les problèmes de casse...) ou parce que l'utilisateur l'a effacé ("normalement, il y avait une copie dans ma boite mail").
    
    Et par expérience, lorsque l'on a passé les boites des utilisateurs d'un répertoire local à un serveur de fichier (pour l'aspect sauvegarde, principalement), l'expérience montre que c'est autrement plus douloureux que réparer une mailbox corrompue.
    
    Au final, ce système est peut-être très bien pour un geek, mais pour une utilisation à grande échelle, je ne suis pas convaincu,
    
    A l'inverse, ce que j'aimerai c'est un format avec un fichier par fil de discution : ce serait le pied pour la gestion des tickets et des listes de diffusions... ;)

  • [^] # Re: Mail.app fait comme ca

    Posté par iznogoud le 05 juillet 2007 à 21:09. Évalué à 2.

    

    Complètement HS, mais j'ai remarqué y'a peu que Mail.app utilise une base sqlite pour stocker tout un paquet d'informations. Fermer l'application, puis aller dans ~/Library/Mail/ et ouvrir avec sqlite3 le fichier "Envelope Index".
    
    On trouvera notamment la liste des adresses mails utilisées pour les auto complétions...
    

    
    sqlite> .schema
    CREATE TABLE addresses (ROWID INTEGER PRIMARY KEY, address, comment, UNIQUE(address, comment));
    CREATE TABLE attachments (ROWID INTEGER PRIMARY KEY, message_id INTEGER, name, type, UNIQUE(message_id, name));
    CREATE TABLE mailboxes (ROWID INTEGER PRIMARY KEY, url UNIQUE);
    CREATE TABLE messages (ROWID INTEGER PRIMARY KEY AUTOINCREMENT, message_id, in_reply_to, remote_id INTEGER, sender INTEGER, subject_prefix, subject INTEGER, date_sent INTEGER, date_received INTEGER, date_last_viewed INTEGER, mailbox INTEGER, remote_mailbox INTEGER, original_mailbox INTEGER, flags INTEGER, read, flagged, size INTEGER, color, encoding, pad);
    CREATE TABLE properties (ROWID INTEGER PRIMARY KEY, key, value, UNIQUE (key));
    CREATE TABLE recipients (ROWID INTEGER PRIMARY KEY, message_id INTEGER, type, address_id INTEGER);
    CREATE TABLE sqlite_sequence(name,seq);
    CREATE TABLE subjects (ROWID INTEGER PRIMARY KEY, subject);
    CREATE TABLE threads (ROWID INTEGER PRIMARY KEY, message_id INTEGER, reference, is_originator);
    

    
    
    addresses <= liste des mails stockés
    attachments <= lien entre un message et un nom de piece jointe
    mailboxes <= structure des mailbox (répetoires etc.)
    etc.
    
    Attention quand même à bidouiller avec modération, c'est du sqlite donc ça ne gère pas les clés étrangères, et je ne sais pas l'impact que peut avoir la suppression d'éléments dans une ou autre des tables sans nettoyer derrière les autres tables.
    
    M'enfin ça ouvre de belles perspectives à qui veut récupérer les adresses mails des contacts d'un utilisateur lambda sous macos, pour peu qu'on ait un accès en local sur la machine. Cela dit, il faut aussi voir que ces bases existent aussi sous thunderbird etc., c'est juste facile à trouver ici ^^

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.