SOGo vs exchange?

SoGo ou l'ouverture et les standards ouverts

• [^]Re: SoGo ou l'ouverture et les standards ouverts

  Posté par Zenitram (page perso, ) le 31/10/2009 à 17:05. (lien). Évalué à 4.

  Zarafa, grand concurrent de SOGo,
  
  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 () le 02/11/2009 à 13:47. (lien). Évalué à 2.

    Zarafa a une version Community, mais c'est plus un produit d'appel qu'autre chose
    
    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 () le 03/11/2009 à 01:05. (lien). Évalué à 2.

      > Zarafa avait deux inconvénients majeurs [...]
      > 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 () le 03/11/2009 à 09:34. (lien). Évalué à 2.

        Z-Push (j'ai pas testé, ça marche bien ?)
        
        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 (page perso, ) le 31/10/2009 à 20:02. (lien). Évalué à 2.

  La prochaine version devrait permettre le DnD dans le module calendrier :-)

Question

• [^]Re: Question

  Posté par André Rodier () le 02/11/2009 à 18:05. (lien). Évalué à 1.

  Bon j'ai essayé, et ce n'est toujours pas possible...
  
  Pour le moment, je resterais donc avec Davical et Thunderbird/Lightning, qui me donnent satisfaction.