Nouvelle version de Kolab Groupware

Posté par  . Modéré par Florent Zara.
Étiquettes : aucune
0
22
juin
2005
Bureautique
Le projet Kolab Groupware vient de sortir en version 2.

Kolab est une solution libre de groupware (traduction française : collecticiel ou synergiciel) sous GNU/Linux qui peut remplacer d'autres solutions propriétaires comme Microsoft Exchange ou Lotus Notes. Kolab permet, en plus des e-mails, de gérer et de partager ses contacts, calendriers (avec gestion des disponibilités) et tâches.

Kolab2 se base sur des composants libres et éprouvés comme OpenLDAP, Postfix, Cyrus IMAP, Apache, ProFTPd, SASL, SpamAssassin, Clamav, ...

Les nouvelles fonctionnalités par rapport à la version 1 sont :
- Support du multidomaine
- Intégration de l’antivirus ClamAV
- Intégration de l’antispam Spamassassin
- Gestion de la notion de serveur maître / serveur esclave
- Gestion fine des quotas
- Intégration de listes de diffusions
- Intégration du client Web "horde" Tous les tâches d'administration quotidiennes peuvent se faire grâce à une interface web claire et le système OpenPKG permet un déploiement rapide et facile de Kolab sur un grand nombre de distributions Linux.

Différents clients peuvent se connecter à Kolab : Kontact (KDE), Outlook grâce à un connecteur (propriétaire) et Horde comme client web (avec IMP et Chronolith). D'autres clients sont en développement (dont une extension pour Thunderbird).

Le projet Kolab est utilisé par le gouvernement allemand et a également reçu le soutient de KDE qui offre un service de groupware utilisant Kolab pour ses contributeurs.

Aller plus loin

  • # Open-Xchange

    Posté par  (site web personnel) . Évalué à 8.

    Avantages/inconvenients face à Open-Xchange ? Kolab me parait être son seul rival (pro) ...

    Ayant testé les 2, j'en sors quelques inconvenients à Kolab:
    - pas possible de tester le connecteur Outlook (Toltec) sans l'acheter, et c'est une partie crucial d'un groupware pour entreprises
    - il utilise ses propres packages, difficile d'ajouter ou modifier un module, ou de personnaliser, ou encore d'en faire un package Debian :)
    + utilise des programmes GPL classiques
    ......

    et des inconvenients pour OX:
    - très difficile d'installation, mais des packages Debian existe (pas testés)
    - nécessite Java + Tomcat, donc très gourmand en mémoire
    + le webmail est très sympa d'utilisation, un must !
    + accès webdav pour les calendriers, contacts, documents
    ......

    Sinon pour OX je peux dire que ça marche bien et que nous l'utilisons en production.

    D'autres avis ?
    • [^] # Re: Open-Xchange

      Posté par  (site web personnel) . Évalué à 4.

      EDIT: je parlais du connecteur KONSEC, j'avais testé le Toltec, pas vraiment convaincant....
      • [^] # Re: Open-Xchange

        Posté par  . Évalué à 2.

        Jusqu'à hier, il y avait une version beta du connecteur Konsec disponible (en anglais et en allemand) . Aujourd'hui je n'ai vu que la version définitive en allemand ( http://download.konsec.com/konnektor/KONSEC_Konnektor_1_de.zip(...) ).

        J'ai testé aussi celui de Toltec et je n'avais pas été convaincu. Je trouve le connecteur de Konsec nettement meilleur : facile à installer et à configurer.
    • [^] # Re: Open-Xchange

      Posté par  . Évalué à -1.

      Difficile a installer ? j'ai réalisé un projet tuteuré visant à intégrer Jabber dans l'environnement de Kolab. L'installation etait assez simple, il suffisait d'installer une Debian et lancer un script qui installer tous les paquets necessaires au fonctionnement avec l'outil openpkg.

      Suffisait de repondre a quelques questions, et l'environnement etait operationnel. (je trouve meme ça trés simple voir les outils mises en oeuvre .... sevreur de mail, ldap ... :) )
    • [^] # Re: Open-Xchange

      Posté par  (site web personnel) . Évalué à 2.

      Je confirme ce que tu dis sur OX à propos de "Très difficile à installer".

      La procédure est longue et fastidieuse.
      C'est peut être un peu le prix à payer pour utiliser des outils reconnus externes à OX.

      Par contre, la dépendance avec Tomcat se comprend plus facilement car c'est une appli qui tourne côté serveur. On ne peut quand même pas être contre toute appli qui marche avec Java.
      En plus, grâce à ca, ils ont repris des librairies Apache qui marchent nickel et n'ont pas -trop- réinventer la roue.

      Pour le webmail, il est bourré de frameset tous pourris. Perso, je n'aime pas.
      Ils ont des progrès à faire côté IHM, ergonomie et procédure d'installation.

      Par contre, je trouve que OX est le projet le plus ambitieux de tous les groupware OpenSource. Ce sera, à mon avis, l'équivalent d'OpenOffice, Firefox, Gimp (ajoutez celui de votre choix) dans leurs domaines, mais pour les groupwares.
      • [^] # Re: Open-Xchange

        Posté par  (site web personnel) . Évalué à 3.

        Par contre, la dépendance avec Tomcat se comprend plus facilement car c'est une appli qui tourne côté serveur. On ne peut quand même pas être contre toute appli qui marche avec Java.

        pourquoi pas un serveur en python :D

        Au niveau IHM, elle est pas très jolie, effectivement, mais très fonctionnelle et convivialle je trouve !
    • [^] # Re: Open-Xchange

      Posté par  . Évalué à 1.

      Avantages/inconvenients face à Open-Xchange ? Kolab me parait être son seul rival (pro) ...

      Il existe OpenGroupeWare
      http://www.opengroupware.org/(...)

      Je ne l'ai pas testé, je ne peux donc pas dire si l'installation est difficile ou pas (il y a cependant tous les packages necessaires pour pas mal de distributions + manuel + FAQ)
      • [^] # Re: Open-Xchange

        Posté par  . Évalué à 10.

        Dans le cadre de mon boulot, on a testé différentes solutions de groupware.

        On a testé open-xchange mais le connecteur pour outlook ne nous a pas satisfait et comme pas mal d'utilisateurs utilisent outlook, il fallait un bon support de ce logiciel.

        On a testé ensuite opengroupware mais il n'y avait pas moyen d'avoir un version d'évaluation du connecteur pour outlook, il fallait commander 5 licences pour pouvoir l'essayer.

        On a également essayé GroupWise de Novell mais on a abandonné quand on a vu qu'il fallait un serveur X sur le serveur pour l'installer.

        On a enfin testé kolab. Contrairement à d'autres commentaires, on a trouvé que le système avec openpkg qui crée un chroot était très pratique. Le connecteur pour outlook fonctionne très bien (d'abord testé toltec puis konsec). On est encore en train de le tester mais il y a de très fortes probalilités que ce soit celui que nous utiliseront.

        C'était juste un petit retour d'expérience ;-)
    • [^] # Re: Open-Xchange

      Posté par  . Évalué à 3.

      Je ne connais pas Kolab mais OX a d'autres avantages :

      + Synchronisation PALM
      + Extensions : SyncML (pour les PDA et autres Smartphone), FAX, VOIP
      http://www.open-xchange.org/oxwiki/OXtensions(...)
      + Clients capables de parler IMAP , http/webdav, LDAP
      + Facile à intégrer avec Samba
      + Wiki : http://www.open-xchange.org/oxwiki/(...)
  • # Toujours pas pour moi....

    Posté par  . Évalué à 2.

    Pourquoi fournissent-ils les sources au format rpm ?
    Pourquoi fournissent-ils les packets pré-compilés pour debian au format rpm ?
    Encore que je ne me fiche pas mal de la 2ème question, je suis sous LFS.
    C'est bien là le problème, d'ailleurs, car depuis l'annonce des premiers développements de cette suite, pas moyen d'obtenir des sources "propres" au format .tar.{bz2,gz}. C'est dommage.
    Peut-être qu'un jour, quelqu'un pourra proposer une doc d'installation de cette suite sur LFS, ou plutôt BLFS, avec des archives des sources compatibles.
    Oui, je sais, on peut toujours installer rpm sur un LFS, et puis Alien, et puis....
    Mais ça me gave. Ce que je voudrais, c'est kolab, pas le reste.
    • [^] # Re: Toujours pas pour moi....

      Posté par  . Évalué à 2.

      En fait tu confonds RPM et Redhat-only.

      Ce format de diffusion est lié à Open-PKG ( http://www.openpkg.org/(...) ) qui permet justement de fournir des paquets qui passent sur la très grande majorité des distributions et variantes d'Unix.

      Sinon CVS reste ton ami, mais il faut savoir que faire tourner Kolab en le "sortant" de son environnement et en utilisant les composants "standards" d'une distribution (postfix, apache et autres) n'est pas très simple.

      Il suffit de cliquer là http://www.kolab.org/download.html(...) pour avoir le choix.

      M
      • [^] # Re: Toujours pas pour moi....

        Posté par  (site web personnel) . Évalué à 2.

        Normalement tu peux extraire le tar.bz2 de l'archive src.rpm.
        en plus y a un script qui va avec qui permet d'avoir quelques infos sur comment se débrouille le packager pour le faire s'installer correctement...

        Après je suis compatissant si tu n'a pas accès a une machine avec rpm dessus pour faire un rpm -i machin.src.rpm et recup le spec + patch + tar.bz2...

        Il y a rpm2cpio qui permet de faire cela, j'ai vu trainer un script .pl avec ce nom sur ma mandriva donc tu dois pouvoir arriver a le faire tourner sur une LFS...
    • [^] # Re: Toujours pas pour moi....

      Posté par  (site web personnel) . Évalué à 7.

      Cette question revient tellement souvent que je me demande pourquoi ça n'est pas dans la FAQ du wiki...
      En quelques mots:
      Kolab s'installe en environnement chrooté.
      Kolab utilise le projet OpenPKG pour ne pas être dépendant d'une distribution particulière et pour s'installer très facilement en chroot.

      Ce qui est décevant dans ton email c'est que tu n'as visiblement pas lu le README de Kolab. Sinon tu saurais que Kolab utilise (via OpenPKG) un RPM particulier, téléchargé avec Kolab. L'installation se lance par un script shell, et c'est vraiment très simple. Pas besoin d'avoir ni de connaître RPM.

      Enfin, puisqu'il est en chroot, Kolab a besoin "du reste" comme tu dis.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Toujours pas pour moi....

        Posté par  . Évalué à 1.

        Oui, enfin, quand je parlais du "reste", je parlais de rpm, d'openpdk sans le savoir, et comme je me suis laissé tromper par cette extention, je suis parti en live sur alien et tout le bla bla.
        Pour ce qui est de l'environnement permettant de faire tourner kolab, nous sommes d'accord.
        C'est ce qui est nécessaire pour l'installation qui me dérange. Visiblement, je ne suis pas le seul (cf le post en dessous du mien).
        Bref, je pense que mon propos a été mal compris (en tout cas certains aspects), car il ne m'étais même pas venu à l'idée de descendre en flame le travail fait par tout ceux qui font vivre kolab, faudrait quand même être sacrément con, surtout que je n'ai jamais pu ni l'installer, ni l'utiliser.
        Je me répète, c'est la façon de le packager qui me gêne.
        Peut-être qu'un jour, soit j'aurais le temps et le courage d'installer openpkg, soit ils proposeront de belles archives comme on aime au format .tar.bz2.
        Bref, je présente mes plus plates excuses pour m'être égaré sur une fausse piste, je vous remercie de m'avoir corrigé, et j'espère qu'un jour j'obtiendrais satisfaction.
        Quant-à la version cvs, j'y a déjà pensé, j'avais fait un essai une fois, mais c'était un tel bazar, car il y avait pleins de dépendances non résolues, que j'ai laissé tomber pour l'instant.
        • [^] # Re: Toujours pas pour moi....

          Posté par  . Évalué à 1.

          tu dit que tu n'as pu installer kolab ?

          A te lire on dirais que tu n'as meme pas essayé.

          Parce que lancer un script shell (qui t'installe tout seul openpkg dans le chroot comme un grand, occasionnelement) je voit pas ce qui peut bloquer, même sur une LFS... (installé sur debian, mandrak^Wiva, SuSE sans problème)

          Et pour les source, elles sont accessible via les src.rpm, et heureusement car (je sais pas si c'est toujours le cas) il fallait modifier les sources de cyrus pour gérer les accent dans les noms de dossiers créés par outlook)
  • # packaging

    Posté par  . Évalué à 2.

    a mon humble avis, il faudrait que les gens de chez Kolab comprennent un jour que openpkg est horrible (tant conceptuellement que techniquement) et que ca ne vaut _VRAIMENT_ pas une bonne documentation avec un .tar.bz2.
    ca leur ferait gagner du temps, et nous (utilisateurs) aussi.

    ca permettrait que les distribs integrent ca "nativement" et donc (parce qu'y a une logique la-dessous) d'augmenter le nombre d'utilisateurs finaux (ce qui ne leur serait pas inutile si vous voulez mon avis, ne serait-ce que pour avoir des rapports de bugs sur le logiciel lui-meme plutot que sur leur installateur nullard ....).

    bref, _jamais_ je n'installerai un openpkg sur un de mes serveurs, moi je veux utiliser les paquets standards de ma distribution preferee ( ou au pire pouvoir faire moi-meme ces paquets sans y passer 6 mois) pour pouvoir avoir :
    1- les options que je veux avec ma distrib,
    2 - les mises a jour de securite (parce que les mises a jour de secu chez openpkg j'ai un gros doute)
    3 - 0 problemes de compatibilite

    bref, ils se compliquent la vie avec un truc que personne n'a envie d'utiliser... et a mon avis ca en freine plus d'un a installer kolab qui pourtant en ont tres envie (moi par exemple mais j'en connais d'autre).

    en fait, je suis de plus en plus decu par 'kdepim'.
    J'ai vraiment le sentiment que de developper kolab (pour certaines entreprises donc ;) est plus important que d'avoir un client mail qui puisse avoir un 'uptime' superieur a 12h sans utiliser 90% de la RAM (ou sans planter...) ...

    je n'ai qu'un espoir : que quelqu'un qui ait du temps se jette dedans pour nous refaire un kmail digne de ce nom pour KDE4 en repartant "from scratch" ....
    L'integration de kmail dans kontact n'est d'ailleurs qu'une pile de "hacks" pour faire marcher le truc, je trouve tout ca bien 'decevant'

    Mik, franchement depite par le chemin que suit kdepim ...
    • [^] # Re: packaging

      Posté par  (site web personnel) . Évalué à 2.

      en fait, je suis de plus en plus decu par 'kdepim'.
      J'ai vraiment le sentiment que de developper kolab (pour certaines entreprises donc ;) est plus important que d'avoir un client mail qui puisse avoir un 'uptime' superieur a 12h sans utiliser 90% de la RAM (ou sans planter...) ...

      je n'ai qu'un espoir : que quelqu'un qui ait du temps se jette dedans pour nous refaire un kmail digne de ce nom pour KDE4 en repartant "from scratch" ....
      L'integration de kmail dans kontact n'est d'ailleurs qu'une pile de "hacks" pour faire marcher le truc, je trouve tout ca bien 'decevant'


      Pour savoir, que reproche-tu a kontact et kmail ?
      J'utilise kmail sur un compte imap d'une quarantaine de dossiers avec plusieurs milliers de mails dans certains et je n'ai jamais de problème (sauf quand je n'ai plus d'espace disque et que je perd mes mails...), y compris quand kmail tourne 24/24
    • [^] # Re: packaging

      Posté par  . Évalué à 2.

      >>>je n'ai qu'un espoir : que quelqu'un qui ait du temps se jette dedans >>>pour nous refaire un kmail digne de ce nom pour KDE4 en repartant >>>"from scratch" ....

      C'est bizarre, j'utilise kmail (en imap) depuis plusieurs années et je le trouve extrèmement solide (jamais de plantage). C'est peut etre un probleme de config. En fait moi j'utilise suse depuis toujours avec kde par defaut et kmail par defaut. Une fois installé je ne touche plus à rien jusqu'à la prochaine distrib et ca marche biggrement bien.
      • [^] # Re: packaging

        Posté par  . Évalué à -3.

        avec x dossiers de 35000 mails ?
        et 4 comptes IMAP ?

        perso, j'essaye meme plus . c'est pire a chaque fois ...

        Mik
      • [^] # Re: packaging

        Posté par  (site web personnel) . Évalué à 4.

        Je confirme la fiabilité de kmail. J'ai des dizaines de répertoires contenant des dizaines de milliers de courriels.
        Je n'ai que quelques demandes à faire aux auteurs de kmail, juste un meilleur système de recherche dans les mails.
        Et puis tant que je suis en train de faire ma lettre au père kmail, je voudrais aussi un correcteur grammatical... pour mes correspondants ;-)
        • [^] # Re: packaging

          Posté par  . Évalué à 2.

          Personnellement, je sais que la requête a déjà dû être refusée un certain nombre de fois (peut-être pour des raisons de sécurité), mais il serait bien que KMail sache gérer correctement les mails HTML avec des images attachées (jusqu'à présent, KMail les met les une à la suite des autres en dessous du texte...).

          Pourtant, je trouve ça très pratique : envoyer quelques photos avec une légende juste en-dessous !
          • [^] # Re: packaging

            Posté par  (site web personnel) . Évalué à 2.

            Le html dans les mails est une extension non prévue par les RFC qui donnent les normes à appliquer.
            Voir le chapitre "La netiquette" sur http://abul.org/article6.html(...) qui donne des liens vers des pages très instructives

            Chez moi, le courrier html part directement dans la corbeille.
            • [^] # Re: packaging

              Posté par  . Évalué à 3.

              C'est exact, maintenant, à mon avis, ces RFC devraient évoluer. La demande de Frédéric est légitime : on devrait pouvoir formater un minimum les messages électroniques envoyés.
              • [^] # Re: packaging

                Posté par  (site web personnel) . Évalué à 2.

                Je suis d'accord, et dans ce cas mieux vaut du HTML que du MSWord avec content-disposition: inline. Franchement, le HTML (sans javascript) est à mon avis la meilleure solution pour formater les mails au delà du text/plain.
            • [^] # Re: packaging

              Posté par  . Évalué à 2.

              Je ne comprends pas... après avoir fait un script Ruby pour justement pouvoir envoyer des mails en HTML, en fait, ce n'est qu'une pièce jointe au format HTML, rien de plus !
              Après, je pense que l'on peut demander à l'application mail de savoir lire ces pièces inline comme le font tous les autres bons mailer.
        • [^] # Re: packaging

          Posté par  . Évalué à -2.

          Personnellement, je sais que la requête a déjà dû être refusée un certain nombre de fois (peut-être pour des raisons de sécurité), mais il serait bien que KMail sache gérer correctement les mails HTML avec des images attachées (jusqu'à présent, KMail les met les une à la suite des autres en dessous du texte...).

          Pourtant, je trouve ça très pratique : envoyer quelques photos avec une légende juste en-dessous !
  • # petite précision à propos de Lotus

    Posté par  . Évalué à 2.

    Petite info : lotus n'est pas qu'un outil de groupware.

    Il permet aussi de développer complètement des applications qui s'éxécutent sur le serveur domino.

    Ces applications sont très étendus et le point fort de l'outil arrive quand on veut faire des worflow. ça va très vite par rapport à d'autres outils.

    Pour ceux qui connaissent, chez mayetic, ils ont un socle lotus.

    Pour ceux qui voudrait voir un site web qui dont l'architecture n'est en fait qu'une base notes, allez sur www.teamstudio.com.

    Sinon, question :
    Lotus est de l'avis de beaucoup un produit qui va mourir. (par exemple, mayetic sont en train de progressivement basculer vers quickplace).
    Aussi, existe-t-il ->une<- solution libre permettant de faire de manière pas trop compliquée les choses suivantes :
    - ged simple
    - workflow
    - interface facile pour envoie de mail
    - appli
    - travail en mode connecté ou non avec réplication (optionnel)

    J'ai commencer à regarder du côté de zope mais je n'ai pas encore eu le temps de m'y pencher assez dessus.

    Des avis ?

    merci d'avance !
    • [^] # Re: petite précision à propos de Lotus

      Posté par  (site web personnel) . Évalué à 1.

      Lotus Notes est un produit qui va mourrir, certainement, mais il aura sans aucun doute un remplacent sous websphere, et ce n'est pas pour tout de suite, trop de grandes entreprises sont sous Lotus.
      Sinon, hélàs il n'existe aucun équivalent, ni dans le monde libre ni dans le monde propriétaire.
      Parc contre en fonction des besoins particuliers, d'autres solutions peuvent convenir. Mais il n'existe pas de remplacent unique.
    • [^] # Re: petite précision à propos de Lotus

      Posté par  . Évalué à 3.

      > Petite info : lotus n'est pas qu'un outil de groupware.

      < trollmode >
      Ouaip, c'est un fourre-tout qui se prend pour un client de messagerie. A choisir je préfère encore Outlook, au moins c'est convivial et fonctionnel !
      < /trollmode >
      Sérieusement, Lotus Notes(client)/Domino(serveur) c'est le tout-en-un proposé par IBM. Le serveur fait smtp,pop,imap,http,ldap,ntp, et j'en passe tellement la liste est longue. Le client était à l'origine une sorte de runtime pour applications notes, avec effectivement des fonctions de ged et de workflow "gentils". Avec l'avènement de la messagerie, le client est devenu avec + ou - de bonheur un client de messagerie/agenda "à la Outlook". Mais comme il n'est pas conçu pour ça à la base, c'est une catastrophe ergonomique et fonctionnelle.

      A priori le produit va évoluer lentement (v7 puis v8) vers un composé de DB2 pour le stockage et Websphere pour les autres fonctionnalités serveur. L'avenir du client est encore flou, même si 2 tendances se dégagent : le client web est de plus en plus enrichi, et IBM parle d'un futur "client léger enrichi" à la xulRunner, mais proprio.

      Pour passer "en douceur" à un équivalent libre, une chose essentielle manque aujourd'hui : un équivalent du connecteur Exchange, mais pour Domino. A ma connaissance il n'en existe aucun pour aucun autre client de messagerie (ah si, y'a le connecteur Lotus pour ... Outlook, fait par MS !)

      Quelqu'un aurait-il des infos/retours d'expérience sur la programmation de tels connecteurs pour un quelconque client de messagerie/groupware ? Est-ce simple/moyen/dur ? Ca se fait forcément en C/C++ ? Etc. Je suis tellement désespéré de me traîner ça au boulot que je suis prêt à ressortir mon compilo pour avoir une alternative viable !
      • [^] # Re: petite précision à propos de Lotus

        Posté par  (site web personnel) . Évalué à 2.

        Encore un qui compare Lotus Notes avec Outlook... Et en plus qui dit de lui "à la Outlook".

        Tout d'abord c'est Outlook qui s'est inspiré de Lotus Notes pour ses fonctionnalités basiques de GED et non le contraire. Ensuite si tu veux comparer avec du MS, il faut prendre Outlook + Exchange + SQL Server + IIS + .... Et encore certaines fonctionnalitées comme le mode déconnecté n'existe nul part ailleurs.

        Certes la partie messagerie a une interface particulière et pas très reussi, bien que ce soit largement amélioré avec les dernières versions.

        Pour ta question sur les connecteurs, je suis surpris qu'il n'existe pas de connecteur... Il y en a bien pour les pda. Sinon si tu veux en faire un, côté techno c'est assez ouvert, il y a des api C fourniées par Lotus assez bien faites, en java ça doit pas poser de problème non plus.
        • [^] # Re: petite précision à propos de Lotus

          Posté par  . Évalué à 2.

          > Encore un qui compare Lotus Notes avec Outlook... Et en plus qui dit de lui "à la Outlook".
          Oui je compare, et en tout état de cause en plus, vu que je me le traîne au boulot depuis plus de 4 ans.
          Comme indiqué dans mon message, je sais pertinemment que le couple Notes/Domino a un champ d'application beaucoup plus étendu. Seulement voilà, les 90% du temps que je passe avec Notes sont pour la messagerie et l'agenda. Et du coup je trouve Notes "un peu léger".
          D'ailleurs dans ma boite on pourrait en théorie n'avoir que des serveurs Domino, mais on a une GED parce que celle de Domino est trop basique pour nous, un serveur Apache parce que quand même Domino en serveur http c'est moyen-moyen, l'annuaire LDAP n'est même pas envisageable à cause des extensions de schémas qui ne sont pas gérées, etc.
          Et il faut arrêter de faire courir la rumeur que Domino fait aussi SGBD ! Il gère des bases de documents et ça fait une très grosse différence (les bases ne sont PAS relationnelles) ! Je garde un souvenir douloureux d'avoir tenté de m'en servir comme tel !
          ...
          ...sniff......sniff, sniff ...Mais ça sent le troll ici ! "LotusNotesCaSeCompareMemePasAvecOutlookTellementCaFaitPleinDeTrucs", sors d'ici !!!


          Allez, pour la route :
          >"...bien que ce soit largement amélioré avec les dernières versions"
          Vrai, même si faire afficher correctement un mail en html relève encore de l'exploit... Encore un peu d'efforts en on va arriver au niveau fonctionnel d'Outlook97 ! Et pour couper court à toute rumeur, sachez que je suis quand même un gros anti-MS de base !
          >"...certaines fonctionnalitées comme le mode déconnecté..."
          C'est vrai ! Exemple : lancer Notes, débrancher 5s le cable réseau, rebrancher... Notes est à moitié planté ! Celle-là effectivement, je ne l'ai vue nul part ailleurs ;o)

          Bon allez promis j'arrête...
          • [^] # Re: petite précision à propos de Lotus

            Posté par  . Évalué à 3.

            Et il faut arrêter de faire courir la rumeur que Domino fait aussi SGBD ! Il gère des bases de documents et ça fait une très grosse différence (les bases ne sont PAS relationnelles) !

            Depuis quand un SGBD est forcément relationel ?
  • # Corrections et infos

    Posté par  (site web personnel) . Évalué à 2.

    s/soutient/soutien/

    Sinon, j'ai lu que le principe de kolab2 ne dependant que de imap. Tout est stocke sous forme de fichier mime, de sorte qu'il sera possible de faire fonctionner des clients kolab avec d'autres serveurs imap par la suite.

    Pour info, les contributeurs de KDE vont maintenant utiliser un serveur Kolab interne pour gerer leurs differentes taches et communications.
  • # Test de Kolab

    Posté par  . Évalué à 5.

    Je viens de tester Kolab et à ma grande surprise, il est léger et réactif. Je travaille avec Lotus par contrainte et la différence est grande.

    Lotus est lourd et pas du tout ergonomique (a mon goût) alors que Kolab est bien plus rapide et simple a utiliser.

    Certes je n'utilise pas le dixème de ce que peut faire Lotus, mais je suis certains qu'au boulot Kolab pourrait très bien remplacer Lotus pour moi et mes collègues.
  • # blackberry ?

    Posté par  . Évalué à 0.

    ya moyen de le connecter à une soluce open source ?
    • [^] # Re: blackberry ?

      Posté par  . Évalué à 1.

      Une mauvaise langue dirait que tu n'as pas tout compris.

      <mode blasé>Des fois je me dit qu'il y a des gens (très fort) qui savent écrire sans savoir lire.</mode blasé>

Suivre le flux des commentaires

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