Journal Créer un gmail libre ?

Posté par  .
Étiquettes : aucune
0
24
jan.
2005
Bonjour,

Suite à l'essai de gmail, et à la comparaison avec d'autres webmail et des clients mail "lourds", j'en suis arrivé à me poser cette question :

Ya t'il un client mail (ou webmail) qui indexe les mails (dans une BDD ?) pour avoir une fonctionalité de recherche "rapide" ?

Apparement les systèmes intègrent de + en + des systèmes de recherche globaux sur le contenu du disque (comme la google deskbar)

J'ai un peu fouillé, mais j'ai rien trouvé comme client mail avec cette fonctionnalité.

Alors je me suis dit , pourquoi ne pas créer un outil "ala" gmail mais libre ? Je pense plutot à un webmail, capable d'aller choper les mails depuis des serveurs (pop ...) et les indexer dans une bdd (mysql ...), et de fournir une interface de visualisation simple et pratique (gmail , javascript avec jpspan ...). On y rajoute une bonne recherche (maison , mysql fulltext ...) , et toutes les fonctionnalités qu'on voudra bien développer.

Avec un peu (beaucoup ...) de php(...) et surtout beaucoup de réutilisation de code (imp...)

Qu'en pensez vous ?
Faisable ?
Interessant / inutile ?
....

Merci d'avance de vos commentaires :)

Célio

  • # Reponses

    Posté par  . Évalué à 7.

    > Qu'en pensez vous ?

    J'utilise un vrai client mail avec un protocole pratique (lire imap).
    Je ne vois donc pas de raison de subir la lenteur et l'anti-ergonomie des webmails. De plus les clients lourds savent très bien gérer la recherche, le tag et mise en couleur des messages, les dossiers virtuels et je dois oublier des centaines de choses. Pourquoi donc s'imposer un webmail quand des solutions bien plus pratiques existent ? J'ai quand même un webmail qui tappe dans mon imap en, vraiment, dernier recours et qui a du servir 3 fois en 2 ans.

    > Faisable ?

    Tout est faisable

    > Interessant / inutile ?

    Le deuxième

    • [^] # Re: Reponses

      Posté par  . Évalué à 1.

      > J'utilise un vrai client mail avec un protocole pratique (lire imap).

      Justement moi c'est parceque j'en ai marre des clients lourd que je cherche dans cette voie.

      > De plus les clients lourds savent très bien gérer la recherche

      Pour mon boulot j'ai plus de 2Go de mails (et j'ai des collègues avec + de 6Go) et chercher là dedans ... j'ai jamais vu un client mail me sortir rapidement des résultats

      Avec une bdd et des mails indexés, on pourrait également indexer les pièces jointes lisibles, rechercher uniquement sur les PJ , ...

      • [^] # Re: Reponses

        Posté par  . Évalué à 5.

        > j'ai jamais vu un client mail me sortir rapidement des résultats

        Sur quels critères fais tu ta recherche ? Sur tout ce qui est contenu du header ca devrait etre instantané. Et même sur le corps du message, je viens de tester evolution sur une mailbox de 100M il sort le resultat en moins de 15 sur une charette de 400Mhz avec un disque bien poussif, d'ailleurs le peu d'I/O me laisse penser qu'il avait déjà indexé la chose.

        De plus si tu as 2Go de mail en vrac le problème est peu être plus simple à resoudre en stockant de manière basique les mails qui ont un rapport ensemble.

        Par exemple ne pas stocker tout l'historique ensemble mais par année. Je doute qu'il y ait beaucoup de cas ou tu ai besoin de chercher dans 10 ans d'archives... et si tu as 1Go de mail par an alors deux conseils, arretes d'archiver les maillings lists, groups.google est la pour ca, et débrouille toi pour recevoir moins de mail car de toute facon tu ne peux pas lire cette quantité de messages [1].

        De même les dossiers virtuels te permettent de ne garder qu'un ensemble de mails qui sont pertinant et de rechercher ensuite dedans.

        > Avec une bdd et des mails indexés, on pourrait également indexer les pièces jointes lisibles, rechercher uniquement sur les PJ , ...

        Quitte a developper pourquoi ne pas ameillorer la recherche des clients qui existent deja ? Je sais qu'evolution index ses mails au fur et a mesure c'est peut etre optimisable.

        [1] Pour information tout les messages de 2003 sur toutes les mailing lists de FreeBSD representent 229,810 mails et 884Mo. Ce qui fait plus de 620 messages par jour et plus de 1 300 000 caracteres soit a peu pres 400 pages par jours (je suis parti sur 500Mo d'information utile).

        • [^] # Re: Reponses

          Posté par  . Évalué à 3.

          Pour les critères c'est bien évidement le corps du message, sinon ce journal n'a aucun intérêt.

          Pour ce qui est de chercher par date ou même sur le sujet je sais bien que les recherches sont très rapides

          Je viens de tester sur le corps dans un thunderbird avec 450mo de mails et un 1.6ghz, et il a tourné pendant plus d'une minute ... en local ... alors en imap n'en parlons pas, et je n'ai donc pas accès à tous ces mails à distance .

          Et sinon si j'ai besoin de chercher sur 2Go de mails ce ne sont pas des mails "en vrac" ou des mails inutiles de mailings lists. Ce sont des mails de boulôt très souvents avec des pièces jointes, ce qui fait vite monter le tout

          > Je doute qu'il y ait beaucoup de cas ou tu ai besoin de chercher dans 10 ans d'archives

          C'est en parti le sujet de ce journal, et supprimer le problème en supprimant son énoncé .... bof bof
          Si tu n'en as pas besoin tant mieux, mais rien que dans mon entourage j'ai plusieurs cas où ce serait très utile, et le fait que google se positionne sur ce marché montre bien que cela répond à un besoin

          > Quitte a developper pourquoi ne pas ameillorer la recherche des clients qui existent deja ? Je sais qu'evolution index ses mails au fur et a mesure c'est peut etre optimisable.

          Peut-être oui, même si je pense qu'ils ont déjà mené une reflexion là dessus, mais le but réel est comme cité plus haut d'avoir toujours accès à ses mails, et donc pas d'indexer une info du disque local, mais qu'un serveur fasse ce boulôt, et soit toujours accessible.

          Voilà

          • [^] # Re: Reponses

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

            Vous êtes en train de discuter sur les performance de la recherche, qui ,n'a rien a voir avec la discussion webmail/client classique.

            Ce qui change, c'est juste l'algo de recherche.
            Développer un bon algo avec un bon indexeur sur un client mail rendra la recherche rapide.

            Et un mauvais algo de recherche sur un webmail ralentira le server, et nuira a tous les utilisateur, même ceux qui ne recherchent pas.

            Je penses qu'il est plus simple de faire un bon algo sur un client mail classique que un bon algo sur un webmail, un webmail demande de bon server web, et ça, c'est pas facile à trouver pour pas cher.

        • [^] # Re: Reponses

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

          les messages de 2003 sur toutes les mailing lists de FreeBSD representent 229,810 mails et 884Mo

          Les grosses archives de mails ne concernent pas que des mails en texte (je suppose que là, pour FreeBSD, ce ne sont (presque?) que des mails texte sans pièces jointes)...

          Mais pour beaucoup d'utilisateurs, l'archive des mails contient également des mails HTML ou de grosses pièces jointes !

    • [^] # Re: Reponses

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

      Je ne vois donc pas de raison de subir la lenteur et l'anti-ergonomie des webmails.

      As-tu essayé Gmail avant de dire ça ? Car c'est justement son ergonomie que je trouve très pratique et bien pensée.

      • [^] # Re: Reponses

        Posté par  . Évalué à 1.

        Bien d'accord avec toi !

        D'après vous que manque t'il aux webmails pour être ergonomiques ?
        A part le drag & drop (que je n'utilise pas dans les clients lourds et dont on n'a pas besoin dans gmail) ....

  • # python...

    Posté par  . Évalué à 1.

    Ba figure toi que j'etait en train de songer à ca dans le cadre de mon apprentissage de python.

    Python+cgi pour l'interface et un classique serveur imap/pop/smtp ( et ftp pour multi desk OS ) pour le stockage .

    Mais j'ai trouvé personne de chaud à cette idée , alors chai pas ...

  • # Decimail

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

    Decimail est peut-être ce que tu cherches. Decimail est un serveur IMAP qui stocke les mails dans une base de données. Ce n'est pas un webmail, mais ça gère (a priori) très bien la recherche.

    cf. http://linuxfr.org/~pacifiko/14571.html(...)

  • # Gmail

    Posté par  . Évalué à 4.

    Bonjour,

    j'ai utilisé ( dans l'ordre ) : Squirrel -> Kmail -> Evolution -> Thunderbird -> Gmail et je trouve que Gmail n'a pas d'équivalent : recherche rapide, ergonomie et design vraiment extraordinaire.

    De plus les 1 Go sont vraiment pratiques., même si je n'en remplis pas plus de 10 %.

    Honnêtement, c'est (pour l'instant) le meilleur outils de gestion de mail que je connais et un équivalent libre avec la même ergonomie et fonctionnalité ferait du bien car il y a un gouffre en Squirrel et Gmail.

    Cependant, je suis pas sur que le choix du php soit idéal.

    • [^] # Re: Gmail

      Posté par  . Évalué à 1.

      > Honnêtement, c'est (pour l'instant) le meilleur outils de gestion de mail que je connais et un équivalent libre avec la même ergonomie et fonctionnalité ferait du bien car il y a un gouffre en Squirrel et Gmail.

      Merci, je commencais à croire que j'etais un peu seul à penser ca :)


      > Cependant, je suis pas sur que le choix du php soit idéal.

      Je n'ai arrêté aucun choix, ni sur la base ni sur le language, mais il se trouve juste que je maitrise php/mysql, et que je connais leurs limites/capacités. Après d'autres languages font surement ca très bien aussi.

      Qu'en est-il des recherche dans d'autres BDD (similaires à FULLTEXT de mysql ) ? Je ne connais pas bien les autres SGBD ...

      Pour info tu pensais à un langage en particulier ? (python ? c'est le seul autre que je connaisse :p )

      • [^] # Re: Gmail

        Posté par  . Évalué à 1.

        Ba python ou des servlets mais l'avantage du php c'est que ça marchera chez la plupart des hébergeurs classiques.

        Sinon, peut-être que stocker les mails dans un fichier sqlite ( mini fichier bd ) ou une BD gérer dans un petit fichier peut aussi être une solution d'implémentation.

        L'idéal est de faire un bon BD Wrapper pour que le choix de la BD soit fait par l'utilisateur.

        Mais c'est clair que gmail c'est classe, c'est un peu le Apple du webmail ;)

        • [^] # Re: Gmail

          Posté par  . Évalué à 0.

          Mais c'est clair que gmail c'est classe, c'est un peu le Apple du webmail ;)


          heu ... mac.com fait aussi du webmail ...

          sinon pour l'idée de l'indexation et Cie,
          je voudrais pas faire de la pub mais je connais un excellent algo/moteur d'indexation lexicographique ( genre sur du mbox ça pourrait marcher [1])
          http://www.lri.fr/~jeremy/Recherche/SearchEngines/index.html?LANGUA(...)
          précédemment utilisés dans un framework de partage de fichier pour une cité U ( orsay ).

          Enfin, JyBy serait probalement le mieux placé pour en parler...

          Concernant l'Interface Graphique, je suis totalement d'accord, GMail est ( je trouve ) révolutionnaire, et vraiment très pratique. SURTOUT quand comme moi on pratique de l'IRC par MAIL ou assimilé.... ( threads de 99 mails par jours / 20 personnes )

          Personnellement, je ne connais pas un seul client lourd adéquat pour mon style de pratique. Quoique je nuancerais l'aspect 'recherche' dans les mails, qui me semble déjà existant et fonctionnel sur la majorité des MUA.

          [1] il _faut_ garder un format de mails compatible/standard.

  • # Altern

    Posté par  . Évalué à 1.

    Ben Altern (www.altern.org) existe deja. Ok y'a pas des Go d'espace disque, masi Valentin Lacambre fait avec ce qu'il a pour offrir ce qu'il peut.
    C'est gratuit et libre (ca tourne sous squirrelmail). Plutot que de reinventer la roue, aider altern est peut-etre une solution ?

    • [^] # Re: Altern

      Posté par  . Évalué à 1.

      Pourquoi pas, mais l'idée était plutôt de développer un logiciel plutôt que de fournir un service

      Ce qui pourrait amener les gens à utiliser cet outil plutôt que squirel, imp, ... et donc proposer de nouveaux services

  • # Pourquoi j'aime gmail ?

    Posté par  . Évalué à 2.

    Ce que j'aime, dans l'ordre :

    - recherche extraordinairement rapide et pratique
    - les "labels" (quand je pense que n'importe quel client lourd pourrait le faire mais qu'aucun n'y avait pensé !)
    - bouton "reply all" qu'on peut utiliser en cours de composition du message
    - filtre antispam
    - interface sobre
    - disponibilité, accès en https

    Ce que j'aime moins :

    - pas de mode multitab utilisable (clic milieu sur un mail/un label ne marche pas)
    - pas de contrôle des sessions ouvertes
    - pas de possibilité de spécifier son email autrement que par un reply-to (et pas de multicompte)
    - interface pas franchement rapide (impossible de lurker une ML de 500 messages par jour ou plus)

  • # XUL ?

    Posté par  . Évalué à 6.

    Ce n'est qu'une idée en l'air, mais pourquoi ne pas utiliser le framework mozilla pour ca ? Tu bénéficierais alors de fonctionalités d'affichage avancées, on pourrait presque imaginer un thunderbird "en ligne". Après il faut voir aussi la lourdeur de l'application...

    Sinon j'avais commencé à coder un webmail en python (sur de l'IMAP), l'avantage étant les bibliothèques existantes. Mais c'est assez dur à gérer, en particulier tous les problèmes de Mime. Et encore je n'avais pas géré les serveurs IMAP pourris. Si ca t'intéresse je peux te passer ma base de code.

    En ce moment je suis sur IMP4 et je le trouve vraiment sympathique. On reste assez loin de gmail mais il est agréable à utiliser et je n'ai pas l'impression qu'on lit mon courrier au-dessus de mon épaule :).

    --
    Thomas

    • [^] # Re: XUL ?

      Posté par  . Évalué à 1.

      J'y avais pensé, mais le problème de XUL c'est qu'il faut un mozilla/firefox pour l'afficher, or c'est loin d'être par défaut partout ...
      Or avec une solution basée sur jpspan, ca fonctionne sur IE / Moz / Safari , ce qui permet quand meme une plus grande portabilité je pense ...
      Mais c'set sur que niveau fonctionnalités en xul ce serait mieux ...

      • [^] # Re: XUL ?

        Posté par  . Évalué à 2.

        Le sujet m'intéresse pas mal donc j'ai fouillé un peu pour tomber sur ca : http://xulwebmail.mozdev.org/.(...) Un Webmail en Php et en XUL, une idée qui me plaît beaucoup, mais le projet est arreté.

        C'est vrai que le problème est l'intégration avec les autres navigateurs... En même temps on ne peut même pas utiliser correctement du XHTML/CSS2 avec IE, et je ne me vois pas faire un webmail sans possibilité de personnalisation. Reste konqueror... A suivre.


        --
        Thomas

  • # Client avec interface type GMail

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

    Si j'ai bien compris, ce qui te plaît dans Gmail, c'est pas tant le fait que ce soit un webmail que l'interface.
    L'idée serait peut-être de créer un client (du type le plus classique, comme thunderbird, développé en C) utilisant une interface similaire à Gmail: tagging, recherche, raccourcis claviers, etc.

    Le travail n'est pê pas si grand que ça, je pense qu'il devrait être possible de réutiliser une grande partie du code de thunderbird. C'est un projet qui nécessiterait au moins un personne très compétente, par contre.

  • # Ce qui existe déjà

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

    Je viens de faire une petite recherche sur ce qui existe déjà.

    Bah y'a pas grand chose. Y'a un truc sur sourceforge qui s'appelle ccmail mais qui n'a apparemment pas démarré.

    Plus intéressant, c'est Zoë, écrit en Java. C'est un truc qui fait un peu tout (serveur smtp, serveur pop, serveur web, application webmail) mais y'a des choses intéressantes.
    http://guests.evectors.it/zoe/itstories/story.php?data=stories&(...)

    Si des gens démarrent un projet, je serais assez intéressé. Aussi en php/mysql de préférence, mais pourquoi pas python.

  • # TMail

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

    J'ai commencé à développer un webmail qui se veut simple et rapide d'utilisation. Je n'ai jamais utilisé GMail, mais a force d'en entendre parler, je finit par comprendre :) Le développement n'est pas terminé, et ca m'a servi surtout a faire une démo technologique de JsRPC (comme XmlHttpRequest mais en javascript)
    L'idée est d'utiliser du javascript pour speeder l'interface et les échanges client/serveur.

    Ca donne ca: http://tmail.txzone.net/(...)

    Une version de dév (un peu plus récente) est dispo ici: http://tmail.txzone.net/dev/(...)

    • [^] # Re: TMail

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

      Très riche tout ça! Félicitations!
      Et n'oublie pas la devise de l'open source: "release early, release often". On attend les sources!
      D'ailleurs, c'est écrit en quel langage?

    • [^] # Re: TMail

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

      Effectivement pas mal TMail, beau boulot

      n'oublie pas de faire l'annonce ici quand tu "le projet atteindra une certaine maturité."


      ya pas, ces requetes RPC c'est l'avenir...

    • [^] # Re: TMail

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

      Magnifique ! c'est du très beau boulot !
      C'est fou les petites merveilles bluffantes qu'on peut faire avec xmlhttprequest !
      Félicitations...

      • [^] # Re: TMail

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

        Mais justement, ce n'est pas fait avec XmlHttpRequest, c'est fait avec javascript/dom, et on obtenir un résultat similaire.
        Potentiellement, cola devrait marcher sous opera :)

        • [^] # Re: TMail

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

          Ah très bien, j'avais mal lu :o)
          Saches tout de même que XMLHttp fonctionne désormais sur Opera 7.60, autant que Gecko et KHTML/NetKit. Je l'ai testé..

    • [^] # Re: TMail

      Posté par  . Évalué à 2.

      Ca a effectivement l'air vraiment bien, et c'est vraiment l'usage que je voulais faire de xmlhttprequest :)

      je pensais juste utiliser jpspan, parceque je l'ai un peu étudié, mais l'idée est vraiment proche de ca pour l'interface
      ( http://jpspan.sourcefourge.net )

      Après ce que je voulais rajouter après le téléchargement des mails, c'est de les stocker dans un sgbd pour indexation et recherche rapide


      Mais ca a l'air vraiment bien, bo boulot !

    • [^] # Re: TMail

      Posté par  . Évalué à 1.

      Youpi :) Enfin Gmail sans Big Brother qui va avec :)

      Sérieux, c'est du bon boulot, mon serveur n'attend plus que TMail :)

    • [^] # Re: TMail

      Posté par  . Évalué à 1.

      niveau rapidité de l'interface chapeau !

      mixer Tmail avec zoe et en ajoutant le fait d'avoir le choix entre folder et label (à la Gmail) et on a notre gmail libre ! :)

  • # Hula, futur gmail libre ?

    Posté par  . Évalué à 2.

    Voilà ce que vont faire les gens de Novell :
    "We will build a JavaScript-based rich client for mail and calendaring, in the style of GMail."
    http://nat.org/2005/february/#15-February-2005(...)

    Hula :
    http://hula-project.org/(...)
    (l'url ne fonctionne pas chez moi, bizarre..)

Suivre le flux des commentaires

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