Bonjour,
J'essaye actuellement de développer un client mail pour GNOME (en GTK). J'aimerais autant que possible ne pas réinventer la roue. Par exemple, j'utilise la libgoa pour les informations de connexion. J'arrive pour le moment à récupérer toutes les informations de l'utilisateur : pour chaque compte, les host IMAP et SMTP ainsi que les information d'authentification.
Maintenant, je dois me mettre aux clients IMAP et SMTP, mais je ne suis pas sûr de la meilleure façon de faire : dois-je utiliser un client dans mon code, ou utiliser un service externe ? J'ai vu par exemple qu'il existe un daemon SMTP, mais je ne suis pas sûr qu'il soit fait pour être utilisé par un client mail. Pareil pour un daemon IMAP. Dans tous les cas, je n'ai pas trouvé beaucoup d'informations sur eux.
De plus s'ils utilisent D-Bus, j'ai peur que ce soit compliqué à utiliser (pas du tout utilisateur-amical).
Comment feriez-vous ? Que me conseillez-vous ?
Je précise que je n'ai pas d'expérience dans le développement d'un logiciel de bureau qui doive s'intégrer dans un écosystème comme ça.
# au pif
Posté par NeoX . Évalué à 6.
ben alors pourquoi réécrire un client email alors qu'il en existe deja tant ?
Bon, sinon, admettons que tu veuilles toujours developper ton propre client email.
Alors tu as raison les daemon SMTP/IMAP/POP sont des serveurs, qui repondent à des clients, donc ce n'est pas d'eux dont tu as besoin.
en GTK, je ne sais pas, mais j'aurais tendance à dire que tu peux explorer le code de certains clients email existant, pour savoir comment ils font, sur quoi ils s'appuient, etc
[^] # Re: au pif
Posté par Boiethios (site web personnel) . Évalué à 2. Dernière modification le 10 juillet 2019 à 11:27.
Merci pour la réponse !
Alors, oui, il existe déjà des clients mails, mais aucun à ma convenance. Le plus proche de mes goûts est Geary, mais il a un défaut rédhibitoire, c'est qu'il n'est pas asynchrone. Quand il y a une erreur de connexion, il bloque l'interface en tentant de se reconnecter. Il a aussi des fonctionnalités manquantes qui vraisemblablement ne seront pas ajoutées, comme le fait de ne pas avoir une adresse d'envoi par défaut.
Peut-être qu'il existe déjà un client à mon goût, mais je n'ai pas trouvé ce que je cherche (et pourtant j'en ai testé beaucoup), à savoir :
Pour les daemons, c'est noté.
Je code mon client en Rust, donc je suppose que je vais me tourner vers:
Ça me fera beaucoup de choses à faire à la main, du coup si quelqu'un a une autre idée, je suis toujours preneur.
Au passage, si quelqu'un est intéressé par mon binding de libgoa en Rust, c'est ici : https://gitlab.com/Boiethios/goa-rs/. Pour le moment, je ne gère que les courriels, mais on peut ajouter des fonctionnalités maintenant que le squelette est fait.
[^] # Re: au pif
Posté par nico4nicolas . Évalué à 2.
Assez d'accord avec le commentaire précédent. Si Geary te plait, contribue ou fork le, ça sera plus constructif et plus rapide que de partir de 0.
Je comprends que le logiciel n'a pas été développé dans le langage que tu souhaites parler (Rust) mais (re)développer un logiciel parce qu'il manque une (ou plusieurs) fonctionnalités, ce n'est pertinent que si les sources du logiciel sont fermées. Un des objectifs du logiciel libre, c'est de ne pas avoir à réinventer la roue à chaque fois, de pouvoir partir de quelque chose d'éprouvé et que quiconque puisse venir apporter une pierre à l'édifice.
[^] # Re: au pif
Posté par Boiethios (site web personnel) . Évalué à 1.
Je ne connais pas le Vala, et je n'ai pas trop envie de m'y mettre. Je préfère utiliser un langage que je connais bien.
De plus, s'il y a des problèmes de blocage, je pense que c'est toute l'architecture qui est à revoir. Si je pars sur une organisation totalement asynchrone dès le départ, je n'aurai pas ce genre de problèmes.
[^] # Re: au pif
Posté par NeoX . Évalué à 2.
heu, y a pas "evolution", le outlook de linux qui fait tout ca ?
[^] # Re: au pif
Posté par BAud (site web personnel) . Évalué à 2.
bin, si.
[^] # Re: au pif
Posté par Boiethios (site web personnel) . Évalué à 1.
La dernière fois que je l'ai utilisé, il était affreusement beugué, et il manquait des fonctionnalités dont j'avais besoin.
[^] # Re: au pif
Posté par NeoX . Évalué à 2.
et faire un rapport de bug, une demande d'amelioration,
ou puisque tu codes, coder toi meme juste la fonctionnalité qui te manque,
ce ne serait pas plus facile que de recoder completement un client email sans savoir ce qu'est SMTP/IMAP/POP, MUA, MTA, MDA
tu gagnerais peut-etre du temps, non ?
# Euh ...
Posté par LaBienPensanceMaTuer . Évalué à 8. Dernière modification le 10 juillet 2019 à 15:54.
Euh … Je crois qu'avant de voir coder un client mail, il serait bon de mieux maitriser le sujet ;-)
Je veux pas être méchant hein … mais si tu te poses la question d'intégrer un "daemon SMTP", c'est qu'il y a quelques lacunes qui risque d'être bloquantes…
Pour t'aider dans tes recherches, regarde un peu les différences entre MTA (Mail Transport Agent), MDA (Mail Delivery Agent), MUA (Mail User Agent).
Dans les grandes lignes, le daemon est le service en écoute côté serveur… c'est le service qui va répondre au requête quand ton client va s'y connecter.
Le protocole SMTP est en charge de traiter les mails entrants. (donc, sur le serveur smtp.TON_FAI.fr, c'est lui qui va recevoir tout les mails avec @TON_FAI.fr).
Les protocoles POP3 et IMAP servent quant à eux à récupérer tes emails (c'est le protocole que quelqu'un qui a un @TON_FAI.fr pour récupérer ses emails via imap.TON_FAI.fr).
De façons plus générale, un client mail a, grosso modo, 2 façons de récupérer les emails:
Si il tourne sur la machine ou le daemon tourne (cas de plus en plus rare), alors il peut aller directement piocher dans la mbox ou le maildir rempli par le daemon.
Si il tourne sur une machine différente du serveur, alors il doit utiliser soit le protocole POP3, soit le protocole IMAP, soit une variante chiffrée de ces deux là.
De la même façon, un client a 2 façons d'envoyer un mail:
Si il tourne sur la machine ou un daemon SMTP tourne, il peut faire un appel à l'executable "sendmail" qui va pousser le mail au daemon (bien souvent via un socket Unix).
Sinon, il doit utiliser le service SMTP exposé par le serveur (typiquement, stmp.TON_FAI.fr) ou sa variante chiffrée (SMTP avec TLS ou SMTPS)
De ce coup, si tu ne veux pas ré-inventer la roue, il faudrait trouver une lib qui implémente la partie "client" des protocoles IMAP, POP3 et SMTP.
Tu peux toujours implémenter à la main hein … SMTP et POP3 sont des protocoles très simples.
IMAP est un poil plus pénible…
Après faut voir ce qui t'intéresse …
Si tu veux mieux maitriser les protocoles de messagerie, alors potasse les RFC des 3 protocoles cités plus haut et implémente les from scratch.
Si le but est plutôt de gagner en compétence sur la programmation graphique sous Linux, alors trouve toi une lib toute faites.
Euh un daemon qui utilies D-Bus… es tu bien sûr ?
Sinon, D-Bus risque d'être le passage obligatoire pour intégrer correctement ton client au gestionnaire de desktop: les notifications sont généralement véhiculées via D-Bus.
Comme dit plus haut, du but que tu poursuis en t'étant lancé dans ce projet.
Ce que je te conseille ? De mieux te documenter sur le MTA, MDA, MUA, POP3, SMTP, IMAP.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.