> Mais alors, qu'est-ce qu'il apporte concrètement ?
1. Cote serveur: de se substituer de facon transparente a un serveur Microsoft Exchange.
2. Cote client: de disposer d'une couche logicielle permettant de construire des clients compatible Microsoft Exchange.
En gros, cote serveur, OpenChange fournit la brique qui implemente la logique serveur necessaire pour communiquer, comprendre et interpreter les requetes de Microsoft Outlook.
> - Par quelle application les calendriers sont gérés ? Sogo ou OpenChange, et avec quel(s) standard(s) ? Caldav ?
OpenChange a developpe une brique logicielle qui abstrait les donnees MAPI pour les stocker dans le backend de son choix.
SOGo stocke les donnees calendriers dans une base SQL (MySQL/PostgreSQL) et peut les presenter de son cote via son connecteur CalDAV.
OpenChange recupere quand a lui ces donnees via son composant mapistore et au travers du backend mapistore de SOGo.
> - Qu'apporte exactement Sogo à Openchange ?
Pour faire court et simple, un backend de stockage performant.
> - Quel est le standard utilisé entre Microsoft Outlook et le serveur OpenChange ?
La suite de protocoles ExchangeRPC (EMSMDB, NSPI, DS_RFR), souvent incorrectement appelee par abus de language "MAPI".
> - D'une manière plus générale, quels sont les standards utilisés, et où peut on trouver un diagramme ou un schéma reprenant les différent composants, et leur rôles.
1. Pour les mails:
Outlook =(MAPI)=> [OpenChange Server -> MAPISTORE] -> SOGo backend -> IMAP Server
2. Pour les calendriers, taches, contacts
Outlook =(MAPI)=> [OpenChange Server -> MAPISTORE] -> SOGo backend -> SQL database
OpenChange fonctionne au dessus de Samba4 (qui peut être déployé comme contrôleur de domaine et avec l'Active Directory). Le serveur OpenChange est un composant/service additionnel a Samba4 qui permet une connectivité native avec les clients Microsoft Outlook (ou clients bases sur OpenChange type evolution-mapi, kmail-akonadi etc.).
La grande différence d'OpenChange par rapport à Zimbra, Zarafa, openXchange and co, c'est que le serveur permet de communiquer directement avec Microsoft Outlook et a Outlook d'être persuade de parler avec un vrai serveur Exchange. Bref, OpenChange ne requiert ni de plugin a installer sur les clients Outlook ni de configuration obscure sortie du grenier. On installe sa suite office et cà marche.
Par rapport a Exchange 2010, la stack cote client d'OpenChange est d'ores et déjà compatible avec Exchange 2010. Nous supportons les communications chiffrées (pre-requis d'Outlook 2010) en natif.
En ce qui concerne le serveur, nous travaillons principalement sur Outlook 2003 pendant les phases de développement - pour des raisons de commodité - au niveau de son comportement.
Le serveur fonctionne également avec Outlook 2007. Un peu de travail supplémentaire est cependant nécessaire pour avoir une interaction utilisateur stable. En ce qui concerne Outlook 2010, nous n'en sommes - c'est vrai - qu'au début des tests. Un peu de travail est necessaire a ce niveau la.
Enfin et cela a son importance, OpenChange fournit une abstraction de stockage qui permet de définir un backend spécifique par répertoire (top-level) de la mailbox. On peut donc facilement imaginer sur le moyen-terme d'avoir (par exemple) depuis Outlook:
- Inbox/Sent Items/Drafts/Outbox geres par SOGo
- Calendar via calDAV sur Google Calendar
- Contacts de Facebook
- Tasks et Notes sur le filesytem
Tout ceci avec une vue unifiée dans Outlook (transparent pour l'utilisateur).
Cela fait parti des extensions du projet sur lesquelles nous souhaiterions réellement mettre l'accent. Nous n'avons cependant ni les ressources humaines pour prendre en charge ce développement ni eu de propositions en ce sens de la part de développeurs.
Ci-joint l'article dans lequel nous avons initialement fait cette proposition:
Finally, we are really interested in providing bindings for other languages, but we have limited human resources. If people are interested in developing PHP, Python or Perl bindings, they are truly welcome!!
Néanmoins, comme il semble y avoir une forte demande en ce sens mais peu de propositions concrètes, j'ai ajouté à la feuille de route potentielle de la biblithèque MAPI 0.6 (HOLODECK), le développement d'un subsystem bindings dans openchange avec un support préliminaire pour PERL et PHP. L'objectif serait de donner une première impulsion, de dynamiser cette axe de développement et de faciliter les contributions de développeurs en ce sens:
C'est en partie un des objectifs de la première release openchange-server WARPCORE HP1 (Hacking Preview) sur laquelle nous allons commencer à travailler. Nous avons pensé le message store provider pour utiliser LDB (http://ldb.samba.org - LDAP-like embedded database) et ainsi bénéficier de mécanismes de stockage de données transparents. LDB permettant le stockage des données dans différentes bases: ldb, tdb ou MySQL, il serait donc a priori enviseagable de stocker/récupérer des données IMAP sauvegardées dans une base SQL. N'ayant pas eu le temps de réaliser des tests réels, je préfère néanmoins rester prudent et utiliser le conditionnel.
Ce n'est pas l'objectif de la bibliothèque MAPI de répondre à ce besoin mais celui du message store provider d'OpenChange. La bibliothèque MAPI n'encapsule que les requêtes émises par un client et n'analyse que les réponses retournées par un serveur. Dans le cadre d'une utilisation sur un serveur c'est le mécanisme inverse qui doit être implémenté: encapsulation des réponses du serveur et analyse des requêtes clients.
En outre, le développement d'un proxy MAPI/Protocol X ne peut être géré par une simple bibliothèque du seul fait du nombre conséquent de paramètres et de mécanismes internes à gérer. Le provider d'OpenChange chargé de cette partie sera néanmoins développé pour permettre l'utilisation de différents support de stockage via des mécanismes de couche d'abstraction. Sur le moyen-terme le développement de proxy MAPI au travers d'OpenChange devrait être possible.
Bien que le protocole, une fois découvert, facilite la tâche, le développement d'une librairie cliente est en revanche beaucoup plus simple que le développement du serveur. D'une part le traitement de l'information est beaucoup plus complexe côté serveur puisqu'il y a de nombreuses intéractions avec un nombre important de composants, et d'autre part, il y a des challenges techniques au niveau serveur qui n'ont rien à voir avec celles de la partie cliente.
Par exemple, OpenChange n'a ni vocation à développer son propre serveur de messagerie, ni l'envie de n'offrir une seule solution existante en terme de backend pour le stockage des mails. Partant de ce constat, nous devons définir une architecture avec des couches d'abstractions qui permettent de greffer des modules Postfix, sendmail, Qmail ou autres; et ainsi de permettre des contributions extérieures en fonctions des besoin. Dans un premier temps, il est vraisemblable que nous commencerons par un backend sqlite pour nos tests puis travaillerons à l'intégration d'un module Postfix.
Il y a également la problématique du stockage des données. Si nous pouvons aisément concevoir un support externe pour le stockage des courriels, qu'en est-il de celui des calendriers, des bases de contacts ou encore des tâches. Comment assurer l'aspect collaboratif et l'accès a des documents partagés. Ou encore comment assurer les liens entre différents objets: rendez-vous et contacts ou contacts et reminders.
Toutes ces questions font parties d'un ensemble de problématiques sur lesquels nous nous penchons afin de définir une architecture robuste et extensible sur le moyen/long terme.
J'ai lu vos commentaires avec beaucoup d'attention et je vous remercie des critiques qui ont été émises puisqu'elle permette d'adapter le contenu du site web et d'aller dans le bon sens.
Cette dépêche était un "premier essai", et nul doute que je ne pourrai qu'en améliorer son contenu lors des prochaines annonces de release.
Pour tenter de répondre à certaines de vos questions:
- L'objectif d'OpenChange est d'offrir de l'intéropérabilité. Cela signifie donc être capable de communiquer avec les serveurs Microsoft Exchange (côté client) mais également de communiquer avec Outlook en natif (aucun plugin à installer dans Outlook).
- En terme d'intéraction avec d'autres projets Open Source, nous travaillons au quotidien avec l'équipe de développement de Samba4 (Andrew Tridgell, Simo Sorce, Andrew Bartlett, Jelmer Vernooij, Stephan Metzmacher) et grâce à la SambaXP avons eu l'opportunité de discuter de manière plus approfondie avec Ronnie Sahlberg (Wireshark).
- Nous avons choisi de nous concentrer sur le plugin evolution, principalement parce que l'architecture était plus adaptée pour un développement rapide. Une première preview technique devrait être disponible au téléchargement dans les prochains jours (version packagée).
- Il est évidemment possible de développer un module pour thunderbird basé sur notre libmapi, mais nous n'avons pas les ressources humaines nécessaires pour prendre en charge ce développement. Si des développeurs de thunderbird sont intéressés par une intégration de la librairie dans leur produit, c'est évidemment avec grand plaisir que nous prendrons le temps nécessaire pour les aider dans cette tâche.
- NSPI est le protocole utilisé par Outlook pour faire de la résolution de noms dans le Exchange Message Store Address Book provider (EMSABP). Il est principalement utilisé dans la création de profiles Outlook (configuration d'un compte Microsoft Exchange) mais également à chaque fois qu'un destinataire est ajouté à un courriel (To, Cc, Bcc).
[^] # Re: Questions
Posté par Julien Kerihuel (site web personnel) . En réponse à la dépêche OpenChange et SOGo : la vraie alternative à Exchange. Évalué à 3.
1. Cote serveur: de se substituer de facon transparente a un serveur Microsoft Exchange.
2. Cote client: de disposer d'une couche logicielle permettant de construire des clients compatible Microsoft Exchange.
En gros, cote serveur, OpenChange fournit la brique qui implemente la logique serveur necessaire pour communiquer, comprendre et interpreter les requetes de Microsoft Outlook.
> - Par quelle application les calendriers sont gérés ? Sogo ou OpenChange, et avec quel(s) standard(s) ? Caldav ?
OpenChange a developpe une brique logicielle qui abstrait les donnees MAPI pour les stocker dans le backend de son choix.
SOGo stocke les donnees calendriers dans une base SQL (MySQL/PostgreSQL) et peut les presenter de son cote via son connecteur CalDAV.
OpenChange recupere quand a lui ces donnees via son composant mapistore et au travers du backend mapistore de SOGo.
> - Qu'apporte exactement Sogo à Openchange ?
Pour faire court et simple, un backend de stockage performant.
> - Quel est le standard utilisé entre Microsoft Outlook et le serveur OpenChange ?
La suite de protocoles ExchangeRPC (EMSMDB, NSPI, DS_RFR), souvent incorrectement appelee par abus de language "MAPI".
> - D'une manière plus générale, quels sont les standards utilisés, et où peut on trouver un diagramme ou un schéma reprenant les différent composants, et leur rôles.
1. Pour les mails:
Outlook =(MAPI)=> [OpenChange Server -> MAPISTORE] -> SOGo backend -> IMAP Server
2. Pour les calendriers, taches, contacts
Outlook =(MAPI)=> [OpenChange Server -> MAPISTORE] -> SOGo backend -> SQL database
[^] # Re: La seule alternative?
Posté par Julien Kerihuel (site web personnel) . En réponse à la dépêche OpenChange et SOGo : la vraie alternative à Exchange. Évalué à 5.
La grande différence d'OpenChange par rapport à Zimbra, Zarafa, openXchange and co, c'est que le serveur permet de communiquer directement avec Microsoft Outlook et a Outlook d'être persuade de parler avec un vrai serveur Exchange. Bref, OpenChange ne requiert ni de plugin a installer sur les clients Outlook ni de configuration obscure sortie du grenier. On installe sa suite office et cà marche.
Par rapport a Exchange 2010, la stack cote client d'OpenChange est d'ores et déjà compatible avec Exchange 2010. Nous supportons les communications chiffrées (pre-requis d'Outlook 2010) en natif.
En ce qui concerne le serveur, nous travaillons principalement sur Outlook 2003 pendant les phases de développement - pour des raisons de commodité - au niveau de son comportement.
Le serveur fonctionne également avec Outlook 2007. Un peu de travail supplémentaire est cependant nécessaire pour avoir une interaction utilisateur stable. En ce qui concerne Outlook 2010, nous n'en sommes - c'est vrai - qu'au début des tests. Un peu de travail est necessaire a ce niveau la.
Enfin et cela a son importance, OpenChange fournit une abstraction de stockage qui permet de définir un backend spécifique par répertoire (top-level) de la mailbox. On peut donc facilement imaginer sur le moyen-terme d'avoir (par exemple) depuis Outlook:
- Inbox/Sent Items/Drafts/Outbox geres par SOGo
- Calendar via calDAV sur Google Calendar
- Contacts de Facebook
- Tasks et Notes sur le filesytem
Tout ceci avec une vue unifiée dans Outlook (transparent pour l'utilisateur).
[^] # Re: Bindings Java
Posté par Julien Kerihuel (site web personnel) . En réponse à la dépêche Sortie de la bibliothèque MAPI OpenChange 0.4. Évalué à 2.
Cela fait parti des extensions du projet sur lesquelles nous souhaiterions réellement mettre l'accent. Nous n'avons cependant ni les ressources humaines pour prendre en charge ce développement ni eu de propositions en ce sens de la part de développeurs.
Ci-joint l'article dans lequel nous avons initialement fait cette proposition:
http://lwn.net/Articles/234642/
Finally, we are really interested in providing bindings for other languages, but we have limited human resources. If people are interested in developing PHP, Python or Perl bindings, they are truly welcome!!
Néanmoins, comme il semble y avoir une forte demande en ce sens mais peu de propositions concrètes, j'ai ajouté à la feuille de route potentielle de la biblithèque MAPI 0.6 (HOLODECK), le développement d'un subsystem bindings dans openchange avec un support préliminaire pour PERL et PHP. L'objectif serait de donner une première impulsion, de dynamiser cette axe de développement et de faciliter les contributions de développeurs en ce sens:
http://wiki.openchange.org/index.php/Libmapi_0.6_HOLODECK
[^] # Re: Outlook, exchange et solution alternative
Posté par Julien Kerihuel (site web personnel) . En réponse à la dépêche Sortie de la bibliothèque MAPI OpenChange 0.4. Évalué à 3.
Je ne parlerai ici que pour OpenChange.
C'est en partie un des objectifs de la première release openchange-server WARPCORE HP1 (Hacking Preview) sur laquelle nous allons commencer à travailler. Nous avons pensé le message store provider pour utiliser LDB (http://ldb.samba.org - LDAP-like embedded database) et ainsi bénéficier de mécanismes de stockage de données transparents. LDB permettant le stockage des données dans différentes bases: ldb, tdb ou MySQL, il serait donc a priori enviseagable de stocker/récupérer des données IMAP sauvegardées dans une base SQL. N'ayant pas eu le temps de réaliser des tests réels, je préfère néanmoins rester prudent et utiliser le conditionnel.
[^] # Re: Excellent !
Posté par Julien Kerihuel (site web personnel) . En réponse à la dépêche Sortie de la bibliothèque MAPI OpenChange 0.4. Évalué à 3.
Ce n'est pas l'objectif de la bibliothèque MAPI de répondre à ce besoin mais celui du message store provider d'OpenChange. La bibliothèque MAPI n'encapsule que les requêtes émises par un client et n'analyse que les réponses retournées par un serveur. Dans le cadre d'une utilisation sur un serveur c'est le mécanisme inverse qui doit être implémenté: encapsulation des réponses du serveur et analyse des requêtes clients.
En outre, le développement d'un proxy MAPI/Protocol X ne peut être géré par une simple bibliothèque du seul fait du nombre conséquent de paramètres et de mécanismes internes à gérer. Le provider d'OpenChange chargé de cette partie sera néanmoins développé pour permettre l'utilisation de différents support de stockage via des mécanismes de couche d'abstraction. Sur le moyen-terme le développement de proxy MAPI au travers d'OpenChange devrait être possible.
[^] # Re: Concrètement ça sert à quoi ?
Posté par Julien Kerihuel (site web personnel) . En réponse à la dépêche Sortie de la bibliothèque MAPI OpenChange 0.2. Évalué à 2.
Par exemple, OpenChange n'a ni vocation à développer son propre serveur de messagerie, ni l'envie de n'offrir une seule solution existante en terme de backend pour le stockage des mails. Partant de ce constat, nous devons définir une architecture avec des couches d'abstractions qui permettent de greffer des modules Postfix, sendmail, Qmail ou autres; et ainsi de permettre des contributions extérieures en fonctions des besoin. Dans un premier temps, il est vraisemblable que nous commencerons par un backend sqlite pour nos tests puis travaillerons à l'intégration d'un module Postfix.
Il y a également la problématique du stockage des données. Si nous pouvons aisément concevoir un support externe pour le stockage des courriels, qu'en est-il de celui des calendriers, des bases de contacts ou encore des tâches. Comment assurer l'aspect collaboratif et l'accès a des documents partagés. Ou encore comment assurer les liens entre différents objets: rendez-vous et contacts ou contacts et reminders.
Toutes ces questions font parties d'un ensemble de problématiques sur lesquels nous nous penchons afin de définir une architecture robuste et extensible sur le moyen/long terme.
[^] # Re: Concrètement ça sert à quoi ?
Posté par Julien Kerihuel (site web personnel) . En réponse à la dépêche Sortie de la bibliothèque MAPI OpenChange 0.2. Évalué à 3.
Cette dépêche était un "premier essai", et nul doute que je ne pourrai qu'en améliorer son contenu lors des prochaines annonces de release.
Pour tenter de répondre à certaines de vos questions:
- L'objectif d'OpenChange est d'offrir de l'intéropérabilité. Cela signifie donc être capable de communiquer avec les serveurs Microsoft Exchange (côté client) mais également de communiquer avec Outlook en natif (aucun plugin à installer dans Outlook).
- En terme d'intéraction avec d'autres projets Open Source, nous travaillons au quotidien avec l'équipe de développement de Samba4 (Andrew Tridgell, Simo Sorce, Andrew Bartlett, Jelmer Vernooij, Stephan Metzmacher) et grâce à la SambaXP avons eu l'opportunité de discuter de manière plus approfondie avec Ronnie Sahlberg (Wireshark).
- Nous avons choisi de nous concentrer sur le plugin evolution, principalement parce que l'architecture était plus adaptée pour un développement rapide. Une première preview technique devrait être disponible au téléchargement dans les prochains jours (version packagée).
- Il est évidemment possible de développer un module pour thunderbird basé sur notre libmapi, mais nous n'avons pas les ressources humaines nécessaires pour prendre en charge ce développement. Si des développeurs de thunderbird sont intéressés par une intégration de la librairie dans leur produit, c'est évidemment avec grand plaisir que nous prendrons le temps nécessaire pour les aider dans cette tâche.
- NSPI est le protocole utilisé par Outlook pour faire de la résolution de noms dans le Exchange Message Store Address Book provider (EMSABP). Il est principalement utilisé dans la création de profiles Outlook (configuration d'un compte Microsoft Exchange) mais également à chaque fois qu'un destinataire est ajouté à un courriel (To, Cc, Bcc).