Sortie de SOGo 1.3.0

Posté par (page perso) . Modéré par patrick_g.
Tags :
14
22
juil.
2010
Technologie
Inverse, société québécoise spécialisée en développement et déploiement de logiciels libres, annonce la sortie de quelques-uns de ses développements :

  • SOGo version 1.3.0 est un collecticiel — ou serveur collaboratif — libre, fondé sur OpenGroupware.org (OGo) et le Skyrix Object Publishing Environment (SOPE) ; il permet de partager ses agendas, carnets d'adresses et courriels. La version 1.3.0 possède de nombreuses améliorations dont possibilité d'inviter des groupes de contacts à des réunions, de partager des calendriers à des usagers externes au système, le chargement progressif des courriels, plusieurs améliorations de performance et bien plus encore.

  • Mozilla Lightning « Inverse Edition » v0.11. 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 (la version 0.9). Plusieurs correctifs, surtout au niveau de la performance, ont été appliqués dans cette nouvelle version. Une version pour Thunderbird 3.1 est actuellement en développement et devrait être disponible vers la fin du mois.

  • Le connecteur Funambol v1.0.8. Ce connecteur permet la synchronisation des calendriers et carnets d'adresses avec une multitude d'appareils mobiles. Cette nouvelle version supporte dorénavant la version 8.5 de Funambol et permet la synchronisation des photos des contacts.

Le tout est disponible sur le site officiel du projet SOGo.
  • # Support officiel pour Debian / Ubuntu

    Posté par . Évalué à 3.

    Merci à la team pour le support officiel Debian et Ubuntu.

    J'avoue que je n'ai pas réussi à l'installer encore jusqu'au bout pour un test grandeur nature mais ceci devrait pouvoir peut etre accélérer les choses.

    La demo en ligne laisse paraitre un très bon produit.
  • # Mise à l'échelle de la solution SOGo

    Posté par . Évalué à 2.

    Pour ma part je suis assez perplexe concernant la structure de la base de données. Je n'ai pas encore testé cette dernière version, mais dans la version précédente j'ai été surpris de voir que plusieurs tables était créées par utilisateur. Quels seront les performances de SOGo avec une base de plusieurs centaines de millier d'utilisateurs.
    L'autre point gênant, à mon avis, est la présence dans de très nombreux champs de la base, des identifiants et mots de passes de connexion à la base.
    À part ce détail, je trouve que c'est un très bon produit, facile à mettre en œuvre et à interconnecter avec une messagerie existante. Il est de plus très facile à prendre en main par les utilisateurs car très proche de thunderbird 2.0.
    • [^] # Re: Mise à l'échelle de la solution SOGo

      Posté par (page perso) . Évalué à 4.

      Les identifiants dans la base de données sont justement pour permettre à SOGo d'aller se connecter à d'autres base de données pour son fonctionnement.

      Par exemple, vous pourriez avoir 10 000 utilisateurs sur une base de données et 10 000 autres sur une autre. Ceci est pratique dans des grands déploiements où il y a une base de données par emplacement géographique et que les liens interconnectant le tout ne sont pas très rapides...

      Pour la structure des tables, elle est très simple en fait. Il y a une table "quick" où l'on conserve certains éléments extraits des événements / tâches / contacts. Cette table est réservée aux consultations "rapides" - comme l'afficage des vues calendriers, la liste des événements, etc. Associée à la table "quick", il y a une table de contenu où l'on conserve la l'événement / tâche / contact _original_ - tel que reçu par SOGo donc nous évitons toutes transformations qui pourraient causer une perte d'informations.

      Au niveau du nombre de tables, des systèmes comme PostgreSQL, Oracle et même MySQL n'ont aucun problème à en gérer plusieurs milliers, en autant bien entendu que la configuration soit bien adaptée au déploiement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.