Sur la conception d'un MAIL-API pour haskell

Je me demandais si ce serait une bonne idée de concevoir une MAIL-API abstraite pour haskell. L'API serait essentiellement conçue comme un EDSL (sans tag).Sur la conception d'un MAIL-API pour haskell

Les termes de l'API MAIL pourraient alors être "évalués" avec un interpréteur commutable. Ces interprètes pourraient alors utiliser une bibliothèque particulière et déjà existante.

Quelqu'un ayant besoin de MAIL n'aurait alors pas besoin de se lier à une bibliothèque de messagerie particulière, mais plutôt de code contre le MAIL-API, à savoir. construire des termes dans l'EDSL et reporter le choix de l'évaluateur.

Günther

Source

2010-11-01 Guenni

Que faites-vous par "MAIL API"? Voulez-vous dire une API pour représenter l'accès à un dépôt mail/mail de type 'mbox' (RFC 4155)? Ou voulez-vous parler SMTP? – ShiDoiSi

Ou des messages MIME? – Yitz

En fait, je voulais dire une bibliothèque client de messagerie. Pour Pop3, IMAP, les clients SMTP. Mais différer les détails de la mise en œuvre, donc techniquement simplement une API. – Guenni

J'ai créé un special interest group for email sur Haskellers.com. Je recommanderais que nous déplaçons la discussion pour ce sujet là-bas.

En ce qui concerne ce sujet: Je ne suis pas sûr de l'abstrait d'une API dont vous parlez ici. Voulez-vous dire abstraction de l'envoi/réception de messages? Analyse et rendu Le premier semble possible, le dernier impossible. Mais je ne suis pas sûr du bénéfice que l'on obtiendra de n'importe quelle abstraction.

Source

2010-11-01 16:40:24

Salut Michael, bonne idée et merci de commencer le SIG. Je n'ai pas encore compris comment poster sur la page. Pourriez-vous me donner un indice? – Guenni

Allez d'abord à la section des discussions. Vous devez être connecté. –

Sur la conception d'un MAIL-API pour haskell

Répondre

Questions connexes