Journal Architecture pour un MUA: Mail User Agent

Posté par  (site web personnel) .
Étiquettes : aucune
10
2
sept.
2010
Bonjour,

J'ai eu l'occasion de travailler sur Tracker ces derniers temps, le nouveau moteur de recherche de bureau soutenu par GNOME et utilisant les ontologies Nopomuk et le langage de requêtes SPARQL standardisé par le W3C. Et j'ai comme idée d'utiliser cette fabuleuse plate-forme pour gérer mes e-mails à la place de Thunderbird.

Pourquoi quitter Thunderbird ? Pour les millions de mails que j'ai en stock, il commence sérieusement à être lent. Et la gestion et le classement commence à être très difficile. Effet direct: je ne regarde plus mes e-mails.

Comment fonctionne tracker ?

Tout d'abord, il y a tracker-store qui gère les accès à la base de donnée. On peut l'appeler via DBus avec des requêtes SPARQL ou pour faire plus rapidement, les bibliothèques tracker permettent d'accéder directement aux fichiers en lecture.

Ensuite, il y a tracker-miner-fs qui une fois lancé va utiliser inotify pour scruter les dossiers dont il à la charge, et indexer les nouveaux fichiers. Si un fichier change, il va appeler tracker-extract pour lire les métadonnées et les insérer dans la base de données toujours avec des requêtes SPARQL.

tracker-store utilise des plugins pour lire les différents types de fichiers, et tout le monde peut écrire un plugin. Dans le cadre de mon travail, j'ai écrit un début de plugin pour le format mbox et les mails au format RFC 2822.


Une autre approche, utilisée par evolution, est que l'application qui gère les données va elle même se charger de mettre à jour la base de donnée tracker avec des requêtes SPARQL. L'inconvénient, si cela n'est pas couplé à l'indexation des fichiers, est que si l'application arrête de gérer certaines données (on enregistre un mail dans ~/Documents), alors on perd les informations sémantiques.

Un MUA basé sur Tracker

J'ai pour idée de séparer mon MUA en trois parties:

- un MDA qui va recevoir les emails des comptes POP ou IMAP et les stocker en local dans des fichiers indexés par Tracker.
- un MUA qui va demander à Tracker la liste des emails indexés sur la machine et les présenter en fonction de plusieurs critères.
- un MTA qui va envoyer les emails par SMTP

Et rien n'interdirait de placer les fichiers emails dans ~/Documents/Banque/E-Mails ou encore ~/Documents/Factures/Electricité et pourtant pouvoir les retrouver dans le MUA.

SPARQL

Je vous ai parlé de SPARQL, il s'agit d'un langage simple pour faire des requêtes dans la base de données. D'abord, comment cette base de donnée est elle structurée?

La base de donnée est composée d'objets. Chaque objet à une URI qui va l'identifier et va avoir des relations avec d'autres objets ou des types de base (string, entier, date, ...). Ces relations ne sont pas au hasard mais normalisées par les ontologies Nepomuk.

En pratique, un objet sera l'instance d'une classe ontologique qui peut elle même hériter d'autres classes ontologiques. Chaque classe est associée à un ensemble de propriétés qui peuvent aussi s'hériter.

Dans SPARQL, les relations sont définies ainsi:


[sujet] [propriété1] [objet1], [objet1] ;
[propriété2] [objet3], [objet4] .


Une propriété spéciale, a permet de donner la classe d'un objet en particulier, l'exemple suivant représente un e-mail:

<file:///home/toto/Mails/1> a nmo:Email ; nmo:messageSubject "Salut!" .


On peut ensuite introduire des inconnues en préfixant le nom de la variable inconnue par ? et on peut construire des requêtes:


SELECT ?x nmo:messageSubject(?x)
WHERE { ?x a nmo:Email . }



Ontologies nepomuk: http://www.semanticdesktop.org/ontologies/nmo/
Tracker: http://projects.gnome.org/tracker/
SPARQL Query: http://www.w3.org/TR/rdf-sparql-query/
QPARQL Update: http://www.w3.org/TR/sparql11-update/
  • # mode aigri=on

    Posté par  . Évalué à 6.

    BeOS le faisait il y a dix ans.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: mode aigri=on

      Posté par  (Mastodon) . Évalué à 10.

      Comme quoi, si le code avait été ouvert, on pourrait en profiter depuis 10 ans...

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: mode aigri=on

      Posté par  . Évalué à 7.

      Gmail va le faire pendant au moins 10 ans.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: mode aigri=on

      Posté par  . Évalué à 8.

      Microsoft le fera dans 10ans 10versions ou pas.
    • [^] # Re: mode aigri=on

      Posté par  . Évalué à 5.

      Si tu veux troller sur BeOS, j'en ai un beau: Haiku est reparti 'quasiment from scratch' au lieu de prendre un noyau existant (Linux, *BSD) pour cloner BeOS.

      Après tout, c'est bien connu qu'il est impossible de faire un OS différent sur un noyau existant: Android, MacOS X n'existent pas..

      Si, si, j'ai le droit, c'est Vendredi!
  • # Standards

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

    Ce serait bien si ça pouvait se baser sur des standards existants. Genre courrier stocké en Maildir.
    • [^] # Re: Standards

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

      De toute façon, l'indexation va se faire de toute façon, quelle que soit le format.

      Pour du mbox, lire le fichier séquentiellement n'est pas bien compliqué
      Pour maildir ou MH, chaque fichier est pris séparément.

      Après, ce qu'il faut c'est un parseur RFC2822/MIME (j'espère pouvoir mettre sous GPL celui que je développe) ... et écrire une jolie interface graphique avec clutter (c'est joli clutter) ou Gtk, ou même Qt pour ceux qui veulent (j'ai plus fait de Qt que de Gtk remarque) et c'est bon.
      • [^] # Question technique ...

        Posté par  . Évalué à 3.

        C'est quoi l'uri d'un mail dans un fichier mbox ? Ça dépend du parseur ?

        Du coup pour l'ouvrir il faut utiliser un logiciel qui comprends l'API Nepomuk et qui connaisse le format de l'URI, si je devine bien ?

        C'est standard sinon la manière d'adresser les mails suivant les différents formats de stockage, dans nepomuk ?
        • [^] # Re: Question technique ...

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

          Effectivement, dans l'absence de spécifications URI pour le format MBOX, il s'agit d'une URI non standardisée ... pour le moment.

          J'ai choisi après plusieurs tentatives le format suivant:

          file:///dir/file.mbox#Message-Id=...&From=...

          Message-ID: header Message-ID du mail (problème, il n'y en a pas toujours)
          From: Ligne From_ du fichier mbox

          Je suis d'abord passée par un numéro (file.mbox#1, ...) qui peut poser problème si le mail change de place. C'est un point à travailler. Mais peut être que mbox est tout simplement à remplacer par maildir ou MH :)
      • [^] # Re: Standards

        Posté par  . Évalué à 2.

        Et GMime ? As-tu regardé ?
        • [^] # Re: Standards

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

          Je ne connaissait pas, mais ça à l'air très intéressant.

          J'avais commencé par regardé libtinymail mais je ne voulais pas ajouter trop de dépendances à mon plugin, surtout que j'ai écrit ce plugin pour des fichiers mbox tout simple avec un Content-Type text/plain uniquement. (application spécifique pour intranet)
      • [^] # Re: Standards

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

        Après, ce qu'il faut c'est un parseur RFC2822/MIME (j'espère pouvoir mettre sous GPL celui que je développe) ... et écrire une jolie interface graphique avec clutter (c'est joli clutter) ou Gtk, ou même Qt pour ceux qui veulent (j'ai plus fait de Qt que de Gtk remarque) et c'est bon.

        Je dis peut-être une bêtise, mais Sylph-searcher semble être assez proche de ce descriptif (au moins pour traiter des mails en maildir ou MH) :

        http://sylpheed.sraoss.jp/en/download.html#searcher

Suivre le flux des commentaires

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