Version imprimable
Bonjour,
S'il vous plaît pour des raisons qui nous sont personnelles, nous voulons développer un serveur de messagerie du style d'Exchange Server et Outlook et nous voudrions savoir si C++ est le langage approprié pour le faire. Sinon où pouvez-vous nous orienter SVP ?
Merci,
Bonjour.
Développer une solution from scratch n'est peut-être pas la meilleure solution en terme de quantité de travail de développement très élevé, là où rechercher et installer une solution existante est plus simple.
Bien qu'Outlook soit très utilisé, il existe d'autres programmes similaires bien moins connus mais tout aussi efficaces.
Maintenant si vous voulez vraiment développer votre propre solution, à mon avis le problème se posera surtout sur le choix des bibliothèques avant le choix du langage.
Il existe assurément des bibliothèques implémentant les protocoles de mail et samba, dans plusieurs langages (dont le C++). On peut aussi plus simplement exploiter le système d'exploitation et les commandes mail de linux ou équivalent Windows Server par exemple.
Pour tout protocole réseau, il convient de penser à libcurl.
Mais pensez plutot à utiliser un logiciel déjà existant.
A moins que vous ayez un besoin complètement exotique, il existe tant de logiciel que votre besoin est probablement couvert.
A mon avis; mieux vaut utiliser des bibliothèques spécifiques IMAP/POP que libcurl.
Et effectivement, plutôt utiliser des solutions comme Zimbra, KOLAb, OBM pour l'aspect serveur. Pour l'aspect client Thunderbird est très bien mais moins user-friendly qu'outlook, et avec les bons plugins on peut gérer des agendas et contacts partagés.
En fait en posant la question, nous savions que les réponses allaient tourner autour des propositions qui existent sur le marché. Mais vous savez il y a toujours des idées innovatrices, la règle N°1 du chercheur ou d'un cabinet d’édition de logiciel est que toute solutions peut être réinventée et l'innovation est toujours possible, les idées tombent toujours du ciel à chaque seconde.
Donc la question de ce qui existent déjà ne se pose pas ici SVP, nous sommes très conscient de ce qui existe déjà. Avant Zimbra (2005) on avait Outlook, Lotus Note et bien d'autres et croyez moi Zimbra n'a pas tout, il y a d'autres concept, d'autres manières de faire qui peuvent surgir sur le marché faire comprendre aux utilisateurs qu'il existent une autre manière de faire qui est de loin meilleur à ce qui existe.
Ceci était simplement pour recadrer la question, nous ne pouvons pas ici dévoiler ce que nous voulons faire sinon ce ne serait plus une innovation. Mais sachez tout de même que nous voulons nous servir du concept de messagerie d'entreprise existant pour implémenter tout un autre concept pas forcément la messagerie d'entreprise traditionnel comme elle est pensée aujourd'hui mais nous voulons partir de ce concept. Ayant utilisé un peu Outlook, nous avons apprécié l'interface et nous voulons partir sur cette base. Nous allons produire deux systèmes : Une solutions client lourd installable du genre de Outlook et une solution web.
Avant de lancer le recrutement des experts pointus dans le domaine que nous recherchons, nous voulions des conseils vers où nous fixer. Et on part simplement sur la base de Outlook et on se dit si je veux reproduit Exchange Server et Outlook et je doit lancer un appel à candidature pour un projet de la conception des déjà finalisée qui chercherais-je ? Des développeurs et architectes JAVA ou C++ ou .Net ou Python ou C#.... ou pensez-vous qu'on doit tabler pour réaliser un tel projet. Ma question pourrait encore se poser de cette manière. Outlook a été développer avec quoi ?
Merci
N'importe quel langage est approprié et plusieurs solutions existent pour certains langages. La question n'a aucun sens. C'est une décision des décideurs techniques qui doit être prise.
Elle a pourtant beaucoup de sens pour moi, beaucoup d'ailleurs, en fait elle est capitale.
Si les décideurs techniques pouvaient, ils ne poserait pas certainement la question. Les décideurs techniques sont un peu limités dans ce sens qu'ils ont beaucoup travaillés avec PHP et ont une idée mais ont besoin de quelques indications pour prendre leur décisions, peut-être leur expertise n'est pas très élevée certainement, ce qui est vrai.
Puisque moi-même je fais partie de l'équipe technique et nous sommes dans l'embarras.
Merci encore
C'est sur que si les décideurs techniques ne connaissent que PHP et tout à coup veulent révolutionner le monde des applis de clients mail lourds vous êtes mal barrés. :roll:
Aussi bonne que soit l'idée, poser une telle question pour ma part ne démontre qu'une chose : vous ne pouvez pas la crééer. Dans le sens où les compétences manquent ou ne savez pas les rechercher ou les appliquer (PHP ? Quid d'un client léger/web alors ? Et osef du client lourd, ou bien utiliser :zekill: Electron).
Donc je me répète : c'est possible dans de nombreux langages (les fameux C++, C#, JAVA, mais pas que, loin de là), et chaque langage a plusieurs solutions (pour ne citer que C++ : wxWidgets, GTK, Qt, ...). La liste (non exhaustive) est longue.
Et je ne parle même pas du protocole réseau ou tout autre aspect...
En ce cas, vous partez trop gros.
Votre système va reposer sur un serveur, donc vous avez la chance de pouvoir faire plusieurs clients et laisser votre logique principale dans le serveur.
Vous pouvez donc ne pas vous poser la question du client lourd, commencez exclusivement par une interface web.
Vous avez deux choix: soit un serveur d'application cliente, soit une application intégralement javascript (ca semble être la mode, mais c'est délicat à faire).
Vous connaissez PHP? C'est un langage adapté à un combo serveur+client graphique web. Profitez-en.
Cela dit, vous n'avez pas à utiliser le même langage pour les serveurs et les clients. Ce qui vous permettra de faire un client lourd quand et comme vous voudrez.
Surtout que PHP gère déjà l'IMAP.Citation:
Vous connaissez PHP? C'est un langage adapté à un combo serveur+client graphique web. Profitez-en.
Après il est difficile de donner des conseils précis si on ne sait pas ce que tu veux faire exactement.
Sinon C++ conviendra, il convient à tout en fait. Outlloolk et Exchange sont certainement développés en C++, et peut être du C# (vu que c'est Microsoft). Quand à OWA, il doit tourner en asp.net.
Plus de précisions
Nous proposons une solution aux problèmes d'asymétrie informationnelle et de cloisonnement informationnel rencontrés par plusieurs entreprises (difficulté d'avoir la bonne information au bon moment). Aujourd'hui plusieurs entreprises se servent des mails, des réunions, du téléphone, des rapports, des séances de coaching pour attribuer et suivre le travail en entreprise. Ce qui génère :
- des milliers de mails
- des réunions, des rapports, des coups de fils qui ne finissent pas
- des lenteurs administratives
- des délais de traitements (SLA) parfois non connus et lorsqu'ils sont connus, ils sont difficilement respectés
- des Clashes de responsabilités
- les managers dépendent uniquement des rapports qui parfois sont biaisés, l'information leur parvient parfois tardivement
- certains employés passent la moitié de la journée, sinon parfois toute la journée à lire des mails et à assister aux réunions
- difficultés adaptation du personnel aux nouveaux postes de travail
- des procédures non claires, non maîtrisées, pas très souvent respectées et qui ne reflètent pas toujours la réalité
- des réorganisations récurrents pour tenter de trouver des solutions managériales
- dans certains pays, ce qui favorise les dessous de table (quand je reçois un mail concernant un travail mon supérieur hiérarchique n'est pas très toujours au courent à moins qu'il soit mis en copie ou qu'il reçoivent le rapport)
Peut-être quelqu'un se reconnaîtra dans ces problèmes cités, si vous ne vous reconnaissez pas, alors vous ne faites pas partie de la cible de notre solutions. Mais une étude de marché à montré que sur 100 entreprises interviewées, 100, utilisent des systèmes de messagerie d'entreprises et 90 se plaignent de ces problèmes.
Entre 2007 et 2015, nous avons mener des recherche pour tenter de résoudre ces problème et nous proposons une nouvelle approche dans le travail en entreprise, une nouvelle manière d'attribuer et suivre le travail.
La conception de la solution a déjà été faite et complètement développée en PHP et elle fonctionne parfaitement en l'espace de 8 ans. Elle fonctionne parfaitement et est déjà éprouvée dans 4 entreprises.
Ceci était la première phase qui s'est faite sans l'intégration des mails (E/S), la deuxième phase donc consistera à transformer la solutions, lui ajouter la possibilité d'envoie et réception des mails à l'extérieur et lui donner une approche de messagerie bien qu'à la base le concept soit différent, ceci au même niveau que les grands systèmes de messagerie. Voilà pourquoi vous nous entendez dès le début parler de Outlook ou Lotus Note. La stratégie est clairement pensée, il faut deux versions de clients lourd et web, ceci pour des buts bien précis.
Tu comprends donc maintenant Bousk, ce n'est pas forcément les mêmes personnes qui ne maîtrisent que PHP qui le feront, nous nous disons simplement que lorsqu'on a un tel projet, on se loue les services des experts.
Merci encore
Je vois des produits métiers qui s'intègrent à outlook via un plugin et permettant de transférer un mail dans le dossier, ou d'envoyer un mail avec trace dans le dossier. Du coup les mails retrouvent leur but premier de communication et ne servent plus à transmettre tout et n'importe quoi, les données de suivi et de travail étant dans le soft.
Oui ceci est vrai quand le soft gère une petite partie de suivi et du travail dans ce cas, il a besoin de temps en temps d'envoyer des mails via Outlook pour des Reminders aux utilisateurs qui restent toujours cramponnées sur leurs mails pour suivre la majorité du travail. Mais quand le soft propose la gestion, attribution et le suivi de la totalité du travail, alors là... on prend du recul et on se demande pourquoi pas rester dans le soft et oser créer une solution plus complète pour le futur.