Ouvrons donc le débat (sachant que PEPS se veut une solution de communication professionnelle, pas forcément B2C) :
Commençons par le plus simple : les labels sont gérés par PEPS. C'est même une des fonctionnalités les plus développées, puisque nous avons des labels privés (comme Gmail), des labels partagés (par exemple un label peut être proposé par l'expéditeur) ainsi qu'un mécanisme de classification des messages basé sur les labels (gestion du besoin d'en connaître, fonctionnalité très B2B). Ce dernier inclut tout le champ de produits complémentaires de messagerie comme "Titus".
Minimum syndical de 1998 : justement, en commençant PEPS fin 2010 (il y a déjà 4 ans, développé à la base pour un grand compte français) le but était de partir sur des bases neuves et pas se limiter avec de l'existant. Du coup, tout le coeur de PEPS est basé sur les API REST nouvelles, ce qui permet plein de nouvelles fonctionnalités qui n'ont pas été évoquées ici (statut réel d'envoi/lecture pour les messages internes, gestion des équipes, envoi de messages aux équipes pour gérer les fonctions de boîtes de délégation, de mailing list, etc.). Nous assumons tout à fait le fait de ne pas être une solution de messagerie "classique".
Par exemple, le serveur IMAP n'a pas été retenu dans la base. Il y a des API dans PEPS suffisantes pour écrire un serveur IMAP en tant que service externe, par exemple via un backend dovecot client des API . Pour moi, il était essentiel d'avoir une codebase propre et modulaire et je pense que nous y sommes arrivé.
-Pour XMPP : nous avons déjà développé une application de chat pour PEPS que nous n'avons pas encore distribuée (initialement dans le cadre d'un projet avec un autre grand compte français). XMPP n'est pas encore supporté, mais oui il le faudrait, nous allons en faire une priorité.
[^] # Re: Retour volontairement agressif pour aller à l'essentiel et provoquer le débat...
Posté par |-| . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 7.
Ouvrons donc le débat (sachant que PEPS se veut une solution de communication professionnelle, pas forcément B2C) :
Commençons par le plus simple : les labels sont gérés par PEPS. C'est même une des fonctionnalités les plus développées, puisque nous avons des labels privés (comme Gmail), des labels partagés (par exemple un label peut être proposé par l'expéditeur) ainsi qu'un mécanisme de classification des messages basé sur les labels (gestion du besoin d'en connaître, fonctionnalité très B2B). Ce dernier inclut tout le champ de produits complémentaires de messagerie comme "Titus".
Minimum syndical de 1998 : justement, en commençant PEPS fin 2010 (il y a déjà 4 ans, développé à la base pour un grand compte français) le but était de partir sur des bases neuves et pas se limiter avec de l'existant. Du coup, tout le coeur de PEPS est basé sur les API REST nouvelles, ce qui permet plein de nouvelles fonctionnalités qui n'ont pas été évoquées ici (statut réel d'envoi/lecture pour les messages internes, gestion des équipes, envoi de messages aux équipes pour gérer les fonctions de boîtes de délégation, de mailing list, etc.). Nous assumons tout à fait le fait de ne pas être une solution de messagerie "classique".
Par exemple, le serveur IMAP n'a pas été retenu dans la base. Il y a des API dans PEPS suffisantes pour écrire un serveur IMAP en tant que service externe, par exemple via un backend dovecot client des API . Pour moi, il était essentiel d'avoir une codebase propre et modulaire et je pense que nous y sommes arrivé.
-Pour XMPP : nous avons déjà développé une application de chat pour PEPS que nous n'avons pas encore distribuée (initialement dans le cadre d'un projet avec un autre grand compte français). XMPP n'est pas encore supporté, mais oui il le faudrait, nous allons en faire une priorité.