La version 1.1.0 possède de nombreuses améliorations dont le support de Apple iCal 4, iPhone OS 3.1, la délégation d'événements, la définition de sources d'authentification et de carnets d'adresses venant d'une base de données SQL, l'ajout d'outils de sauvegarde / restauration des données utilisateurs, un support de base de S/MIME, le support pour WebAuth et bien plus encore.
Inverse annonce aussi la sortie du Mozilla Lightning « Inverse Edition » v0.9.7. Cette version, destinée à Mozilla Thunderbird 2, propose un ensemble de correctifs et améliorations par rapport à la dernière version stable disponible pour Thunderbird 2, soit la version 0.9. Dans cette nouvelle version, la fonctionnalité de délégation a été ajoutée et plusieurs correctifs ont été appliqués.
Le tout est disponible sur le site officiel du projet SOGo. SOGo
Créé en 2004, SOGo est un serveur collecticiel (partage d'agendas, carnets d'adresses et courriels) dont l'architecture est axée sur l'extensibilité de façon à permettre son utilisation simultanée par des milliers d'utilisateurs. SOGo fournit une riche interface Web basée sur la technologie AJAX, offrant des fonctionnalités, une apparence et une expérience utilisateur proches de celles de Thunderbird / Lightning, tout en supportant également plusieurs clients lourds par l'utilisation de protocoles ouverts tels CalDAV, CardDAV et GroupDAV. De plus, SOGo conserve les données des utilisateurs dans des formats standards tels que vCard et iCalendar.
Lightning
Lightning est un projet de greffon pour Mozilla Thunderbird de la Fondation Mozilla. Il s'agit d'ajouter les fonctionnalités de calendrier/agenda/gestion de tâches au client de messagerie. Lightning vise à proposer une alternative crédible à Outlook, le PIM de Microsoft.
Aller plus loin
- SOGo (29 clics)
- Inverse (15 clics)
- changelog (1 clic)
- Mozilla Lightning (3 clics)
# SOGo vs exchange?
Posté par pampryl . Évalué à 8.
Du coup, est ce que dans un contexte professionnel il lui manque quelque chose de significatif vis à vis des plus connus comme exchange?
# SoGo ou l'ouverture et les standards ouverts
Posté par AP . Évalué à 3.
Bref, SOGo est à suivre de près.
(...) Après un petit test, le drag'n drop n'est toujours pas implémenté dans le calendrier. Des collègues de travail à qui j'avais demandé de tester la solution avaient trouvé ce manque d'ergonomie rédhibitoire. Zarafa, grand concurrent de SOGo, semble plus abouti côté web & AJAX...
[^] # Re: SoGo ou l'ouverture et les standards ouverts
Posté par Zenitram (site web personnel) . Évalué à 4.
Mouais. J'ai toujours du mal avec les logiciels à moitié libre :
- Zarafa a une version Community, mais c'est plus un produit d'appel qu'autre chose : tu veux un truc? "Passe en version proprio, ça y est".
- SOGo : une version, tout est libre.
Je comprend que l'ergonomie peut être rédhibitoire.
Mais pour moi, le fait d'avoir du proprio dès que je veux un truc un peu plus poussé est aussi rédhibitoire (je perd tout l'avantage du libre, je n'ai aucune envie de m'emmerder à gérer des licences par installation ou nombre d'uitlisateurs)
Vivement un produit libre pour toutes les fonctionnalités qui propose une meilleure ergonomie!
[^] # Re: SoGo ou l'ouverture et les standards ouverts
Posté par Larry Cow . Évalué à 2.
Si je me souviens bien, le seul vrai manque de la "Community" est le connecteur Outlook. Qui n'existe pas dans SOGo, libre ou pas. Donc bon.
D'autant que Zarafa avait commencé, avant d'ouvrir son code entier, par libérer son composant ActiveSync "over the air" en PHP (aka ZPush). Leur entrée dans le monde du libre est récente et progressive (et pas forcément terminée).
À mon niveau, Zarafa avait deux inconvénients majeurs :
* une interface web qui singe Outlook, et donc n'est pas super pertinent dès qu'on cherche à encourager Thunderbird sur le poste client
* un découplage restreint (quoique meilleur que - disons - Zimbra) : il est son propre serveur de stockage (par contre, on peut garder Postfix/Exim pour toute la partie transport)
Sur ces deux points, SOGo est bien plus sexy :
* l'interface web suit d'aussi près que possible le couple Thunderbird+Lightning, et permet donc d'envisager une approche "TB au bureau, SOGo en déplacement" crédible
* il fonctionne en simple surcouche à une configuration imapd+smtpd existante.
Ceci étant, Zarafa a l'avantage de fournir une solution de synchronisation de terminaux mobiles excessivement simple avec 95% du marché (WinME, iPhone, Symbian) là où SOGo - bien que plus ouvert et extensible - complique un peu le jeu (nécessite d'avoir un serveur Funambol, donc un serveur d'appli Java).
[^] # Re: SoGo ou l'ouverture et les standards ouverts
Posté par herodiade . Évalué à 2.
> un découplage restreint (quoique meilleur que - disons - Zimbra) : il est son propre serveur de stockage
Je suis d'accord avec ça. Pour avoir subit Zarafa en production, stocker les mails en bdd
- est vraiment une fausse bonne idée, il faut des énormes serveurs pour tenir la charge qu'un simple imap sur maildir peux encaisser sans efforts, c'est frappant. peut-être à cause du maintient des indexes, des contraintes d'intégrité, des méthodes d'accès (passer par un intérpreteur et query planner sql), ou de la concurence/des verroux ...
- rends les migrations/changements/adaptations/réparations à chaud difficiles ; ça fait perdre énormement de souplesse et de possibilité de rattraper les boulettes, par rapport à un format de stockage de mail classique où l'on peux manipuler les mails directement avec des outils courants ou quelques lignes de script, déplacer/répartir quelques mailboxes sur un autre serveur, faire des backups incrémentaux et restaurer mail par mail, remplacer un deamon IMAP ou LDA qui ne convient pas/plus, etc.
- Situation dans leur cas aggravée par le choix d'une structure de bdd collant au plus près (sans trop d'abstraction quoi) aux contraintes de MAPI, ce qui la rends assez imbitables (avec des colonnes contenant des champs de bits, les mails décomposés en "properties" et splittés sur x rows, etc). Schéma non documenté, bien sûr.
Cette différence d'approche (Zarafa monolithique et SOGo "intégrable") est aussi sensible en ce qui concerne les choix de protocoles d'accès privilégiés.
Dans le cas de Zarafa, on a pour protocole principal (celui de l'extension Outlook avec laquelle ils font leur beurre) une popotte maison (des requètes MAPI encapsulées dans du SOAP), et en guise de complément du pauvre un peu délaissé,des backends IMAP et iCal-over-http (oui oui, même pas du CalDAV) très frustres et probablement très peu utilisés (c'est ce que je déduit du fait qu'elles sont archi buggués). Ok, et de l'ActiveSync via Z-Push (j'ai pas testé, ça marche bien ?). Le filtrage/tris coté serveur n'est accessible que par le proto de leur client Outlook lourd (inaccessible depuis les autres clients, bye bye thunderbird), idem pour les carnets d'adresse. Pensez-y : si vous migrez hors de Zarafa, vous perdez les règles de tris et les contacts (et quelques mails si vous subissez autant de bugs que moi avec leur passerelle IMAP)...
A l'opposé, SOGo semble avoir un parti pris sans concession pour les protocoles standards, ce qui rejoint ton constat au sujet de sa capacité d'"intégration" (avec d'autres softs). Le support CalDAV est impec, les tris sont en Sieve (tout frais, mes platres), les contacts accessibles en CardDAV (déjà !) et/ou GroupDAV, le mail est délégué au serveur IMAP de son choix (qui saura surement gérer ça mieux q'un group/bloat-ware) sans réinvention d'un proto de mail-over-la-roue... sans parler des contributions à Thunderbird/Lightning (justement en vue d'améliorer le support des protocoles standards, et aussi de donner acces aux infos de disponibilité/freebusy, etc...). L'extension Outlook suggérée (Zideone, en béta qui fait peur) se contente elle-même d'ajouter à l'infâme le support des standards qu'il aurait toujours du avoir, ce qui peut aussi le rendre utile pour communiquer avec les groupware concurents. C'est l'opposé du vendor lock-in.
Par contre, un avantage à mes yeux en faveur de Zarafa, c'est qu'il ne fait pas tout pour faire peur à l'admin : les dépendances sont limités, c'est tout en C++ pas trop jojo mais "devinable" sinon lisible, les fichiers de conf sont dans /etc (et ont une syntaxe bateau), les logs dans syslog, les libs dans /usr/lib, les données statiques dans /usr/share, ça se compile bien (./configure ; make ; make install), ils fournissent des packages très propres en i386 & amd64 pour beaucoup de distros (et c'est facile de les refaire soi même). Bref, si vous avez installé quasi n'importe quel logiciel serveur du monde libre récement, d'apache à postfix ou exim en passant par postgresql ou mysql ou dovecot ou bind ou openldap..., vous ne serez pas dépaysés.
Tandis que coté SOGo, tout semble fait la façon la plus gratuitement originale possible (par rapport à ce avec quoi les admins sont généralement habitués à travailler). Tellement bizarre pour moi que j'ai renoncé de ce fait à l'utiliser en prod (à la place de l'autre zouave) de peur de ne pouvoir le comprendre, diagnostiquer, réparer, maintenir, reconfigurer ou upgrader, et malgré ses indéniables charmes (fonctionalités, souplesse et standards surtout). Codé en Objective-C (cool, mais du coup je crains qu'il n'y ai pas bcp de monde qui envoi des patchs, et donc que les bugs restent là), reposant sur une large tripotée de libs obscures et interdépendantes (et pas présentes sous debian, centos, fedora ni ubuntu) qui viennent d'un projet semblant à l'abandon (opengroupware), et qui sont stockées dans des dépots mercurial (yo, encore un truc à apprendre), et qu'il faut patcher (les libs, vous suivez ?) spécialement pour le SOGo ; dépendance forte à GNUstep (t'a déjà mis ça sur un serveur non Apple ou NeXT cher confrère ?), y compris pour le stockage de la conf (à mort la Linux Standard Base) et aussi pour son format. Quand tu a réussi à le compiler une fois (et make-installé des trucs qui vont se coller dans les coins les plus improbable du système, fait des ldconfigs à tour de bras pour que ça passe), puis mis en prod, je pense que tu espère ne jamais avoir à l'upgrader. Dommage. Quelqu'un a-t-il osé l'utiliser en prod parmis vous ?
[^] # Re: SoGo ou l'ouverture et les standards ouverts
Posté par Larry Cow . Évalué à 2.
Je n'ai pas testé dans le cadre de Zarafa, par contre j'avais sauté dessus quand il était sorti en "standalone". Il n'avait pas été jusqu'en production (besoin trop discret), mais c'était à l'époque bluffant de pouvoir connecter les derniers bidules-trucs mobiles à la mode à une solution libre. Qui plus est en PHP facile à bidouille - par opposition aux solutions Java nécessitant une chaîne de compilation un peu lourdingue.
sans parler des contributions à Thunderbird/Lightning
J'avoue que l'extension "Integrator" est foutrement séduisante, au moins sur le papier.
et qu'il faut patcher (les libs, vous suivez ?) spécialement pour le SOGo ; dépendance forte à GNUstep (t'a déjà mis ça sur un serveur non Apple ou NeXT cher confrère ?)
A priori, sur une Debian testing, cette dernière version passe presque toute seule. Il faut juste penser à installer (à ce jour) libmemcached3 depuis sid. Le dépôt fourni par Inverse dispose d'une version fonctionnelle de SOPE.
je pense que tu espère ne jamais avoir à l'upgrader.
J'avoue que c'est un peu le problème. Ludovic, aurais-tu des retour à nous faire partager là-dessus?
Quelqu'un a-t-il osé l'utiliser en prod parmis vous ?
Pas encore, mais ça me démange fortement.
[^] # Re: SoGo ou l'ouverture et les standards ouverts
Posté par Ludovic Marcotte (site web personnel) . Évalué à 2.
# Question
Posté par André Rodier . Évalué à 2.
Avec l'extension pour thunderbird, comment puis-je spécifier un modèle pour les informations de disponibilités des contacts, pour organiser des meetings ?
Je voudrais pouvoir spécifier un modèle, comme avec Evolution, par exemple http://mycalendar.net/freebusy/%u@%d/freebusy.
Ainsi, lorsque j'organise un meeting, c'est assez pratique de voir la disponibilité des contacts.
Merci
[^] # Re: Question
Posté par André Rodier . Évalué à 1.
Pour le moment, je resterais donc avec Davical et Thunderbird/Lightning, qui me donnent satisfaction.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.