Journal Kolab c'est excellent ...

Posté par  .
Étiquettes : aucune
0
24
avr.
2007
... sauf que ça sert à rien.

Les types de chez Kolab ne se rendent pas compte qu'ils ont une mine d'or sous la main : une solution de Groupware entièrement prête, qui marche absolument nickel, stable, scalable, prête pour l'entreprise, libre, avec une interface d'administration qui marche, etc... Exactement ce qu'il faut pour remplacer Microsoft Exchange.

Le problème vient de la connexion avec les clients :
1. Plugin Outlook pas libre et proprio (par une boîte externe), donc déjà ça écarte pas mal, mais on peut utiliser les mail (IMAP) et le calendrier (LDAP) quand même ;
2. Pas de support CalDAV, et ça vire Mozilla Sunbird et Apple iCal (pour OSX 10.5).

C'est le non support du CalDAV le pire, avec lui on aurait pu contourner le phénomène en utilisant Sunbird pour le calendrier et Outlook pour le reste, mais non.

En gros, tout est prêt, mais on ne peut le connecter qu'avec Kontact.

Et moi qui voulait le déployer dans une entreprise de cosmétiques ... C'était trop beau ...

Quel gâchis.

  • # Je me suis dit la même chose

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

    Je cherchais un système groupware pas trop mal, et ai regardé un peu Kolab.
    Et même conclusion : un fort potentiel, mais trop centré sur Windows+Outlook ou Linux+Kontact.

    Moi qui ai l'habitude d'un Horde qui se connecte partout, ça m'a refroidi.
    Vivement la prochaine version de Horde, CalDAV est dans le CVS mais pas encore "stable", et j'espère que je pourrai avoir Thunderbird/Sunbird qui marche...

    (oui oui, je pense à contribuer... Mais ce sera pour Horde, plus ouvert à la base)

    • [^] # Re: Je me suis dit la même chose

      Posté par  . Évalué à 2.

      Le problème c'est qu'on a pas trop trop de serveur CalDAV, à part un truc en Java et un truc en PHP/Postgres.

      • [^] # Re: Je me suis dit la même chose

        Posté par  . Évalué à 1.

        Et ce truc la ?

        http://rscds.sourceforge.net/

        (c'est packagé debian en plus)

        • [^] # Re: Je me suis dit la même chose

          Posté par  . Évalué à 1.

          Mhhhh c'est peut-etre bien ça le truc en "php/postgresql" dont tu parles :-)

          Cela dit, je ne vois pas trop ce qui te derange avec cette solution ?

          Apache + php + postgres c'est pas quelque chose de très difficile à mettre en oeuvre et n'importe quelle boite (qui a donc un interet à avoir un serveur caldav) a deja ça qui tourne à coté pour les 42 applis de son intranet :-)




          ... au moins c'est pas une bouse en java *cough*

          • [^] # Re: Je me suis dit la même chose

            Posté par  . Évalué à 2.

            Oui c'est bien ça, mais je sens que je vais devoir faire tourner MySQL *et* Postgres sur la même bécane ou alors porter leur applie interne vers Postgres (que j'ai développé cet été, dont certaines requêtes étaient trop complexes pour la couche d'abstraction SQL de CakePHP).

          • [^] # Re: Je me suis dit la même chose

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

            Le problème c'est que les boites n'aiment pas avoir 50000 backend.
            C'est plutôt aux applis de s'adapter.

            Et la, pour le moment, ce logiciel a l'air prometteur, mais annonce brut de fonderie qu'il est pour PostGres pour de bonnes raisons. Un décideur dans un boite ne verra pas son SGBD (genre Oracle ou MySQL) donc il sait qu'il n'aura pas d'admin, donc pas de compétences, donc va dire "non".

            Etre un projet intéressant, c'est aussi savoir s'adapter aux contraintes d'une entreprise... Ou de moi, qui connait que MySQL pour le moment.

            C'est, je trouve, une des grandes forces de Horde (je sais, je me répète) : il lui manque beaucoup, mais à la base il est conçue pour s'adapter à tout type de configuration (comme les projets phares Open-source qui tourne aussi sous Windows ou Mac... ;-) ). Mais du coup ça avance plus lentement :)

            • [^] # Re: Je me suis dit la même chose

              Posté par  . Évalué à 2.

              A mon avis je pense que je vais me lancer le codage d'une couche d'abstraction pour rscds, c'est le seul point manquant imha.

          • [^] # Re: Je me suis dit la même chose

            Posté par  . Évalué à 2.

            Je viens de tester, c'est un logiciel excellent !

            L'interface d'administration est super sympa, traduite en français, ... Le tout m'a l'air très complet et c'est très simple à installer.

            Je sens que je vais tout faire à la main, sans utiliser un groupware intégré.

      • [^] # Re: Je me suis dit la même chose

        Posté par  . Évalué à 1.

        Pas facile a trouver, mais celui d'apple doit tenir la route

        http://trac.calendarserver.org/projects/calendarserver

        • [^] # Re: Je me suis dit la même chose

          Posté par  . Évalué à 2.

          A merde, ca a beau être du python, c'est pas sur que le code tourne ailleurs, apparemment ils ne font pas de tests sous d'autres OS que Mac OS X.

    • [^] # Re: Je me suis dit la même chose

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


      Moi qui ai l'habitude d'un Horde qui se connecte partout, ça m'a refroidi.


      Oué enfin on peut brancher horde sur kolab parfaitement (d'ailleurs c'est expliqué en détail sur le wiki de kolab)

      C'est ce que j'ai chez moi et j'utilise donc :
      linux+kolab sur mes ordis @home et horde ailleurs

      il y a une compatibilité totale avec horde (y compris calendrier, ...) donc aucun problème avec kolab.

      Franchement, kolab est un produit magnifique je trouve, qui fonctionne bien, assez simple de configuration (surtout qu'il est déjà integré dans mandriva par exemple, donc encore plus simple)

      Maintenant, que les connecteurs outlook soient proprio/payants ne me pose pas de problème, surtout que le but est bien de favoriser un outil proprio et payant... et surtout que kolab saibien !

    • [^] # Re: Je me suis dit la même chose

      Posté par  . Évalué à 1.

      Bon titre de commentaire, comme ça, je n'ai pas à le changer ;-) !
      Ceci étant, avec l'arrivée de qt4, et de kde4, je ne vois pas ce qui empêcherait de faire tourner kontact sous windows (hé oui, on n'a pas toujours le choix de l'OS installé sur la machine du boulot) et de profiter ainsi de toute la puissance d'un serveur kolab.
      Ça fait des années que j'attends une solution de goupware, surtout pour le support d'un calendrier partagé. À une époque, on avait même installé la suitespot de netscape, qui comprenait un serveur de calendrier, mais les besoins de formation étaient trop lourds à l'époque, car il fallait installer, configurer la partie serveur et les clients, et former les utilisateurs non seulement à netscape, mais aussi au client mail, au client calendrier, etc.
      Maintenant, les gens savent se servir de firefox, de thunderbird, et il ne resterait plus qu'à les former à la partie calendrier.
      Par ailleurs, passer de firefox/thunderbird à kontact ne présenterait pas de grosses difficultés, puisque les interfaces sont à peu près les mêmes.
      Donc, je pense pouvoir attendre encore quelques mois...

      • [^] # Re: Je me suis dit la même chose

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

        Mais alors, où est la liberté de choix?
        Je ne veux pas que mes utilisateurs soient forcés d'utiliser Kontact (même si ensuite ils ont le choix Linux/Windows), ça reviendrait pour moi exactement comme faire un site compatible que IE.

        Vivement un ensemble de logiciels inter-opérables coté Calendrier...

        • [^] # Re: Je me suis dit la même chose

          Posté par  . Évalué à 2.

          On ne s'est pas compris....
          Mon commentaire allait plutôt dans le sens d'une pré-réponse à la question posée par zyphos ci-dessous (https://linuxfr.org/comments/825579.html#825579 ) [IPOT powa !]
          Je ne voulais absolument pas signifier que la solution kontact sous windows + kolab était l'ultime solution, mais plutôt que c'était probablement une solution viable. Et puis tant qu'à avoir le choix, j'aimerai bien voir un connecteur pour lightening ou sunbird, en plus de ce qui existe déjà.

  • # Je me suis dit la même chose

    Posté par  . Évalué à 6.

    Mais je précise juste que, pour compenser, les boites qui développent les plugins pour Outlook sont les plus gros contributeurs au code de Kolab.

  • # euh ....

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

    "et le calendrier (LDAP)"

    Tu veux dire ... contact ?

    Dans LDAP tu n'as que les contacts des gens de l'entreprise et les contacts globaux externe (qu'il faut entrer à la main dans l'interface de kolab en tant qu'admin).

    Tout est boîte IMAP dans kolab (les notes, les calendriers, les boites contact, ...). Tous les événements, contacts, ... sont des courriels dans ces boîtes.

    Kolab sans kontact ou plugin outlook (et il existe un plugin thunderbird/sunbird), tu n'as que le courriel de réellement fonctionnel.

    • [^] # Re: euh ....

      Posté par  . Évalué à 2.

      Le plugin thunderbird/sunbird est dit comme instable.

      • [^] # Re: euh ....

        Posté par  . Évalué à 1.

        Héhé c'est un sujet qui tombe à pic ^^, je dois virer GroupWise (une merde de chez Novell...). Vous pensez quoi de eGroupWare ?

        • [^] # Re: euh ....

          Posté par  . Évalué à 1.

          Je ne l'ai pas testé. Mais après une petite étude de marché rapide faite par mes soins. C'est le seul groupware à fournir un connecteur Outlook et PDA gratuit (via funambol).

          Si Kolab avait ces connecteurs gratuits et/ou Kontact était porté de manière utilisable sous Windows (sans passer par CYGWIN, même avec Cygwin il ne fonctionne pas correctement, et permettant le drag&drop), il aurait été mon premier choix.

        • [^] # Re: euh ....

          Posté par  . Évalué à 1.

          J'utilise Egroupware depuis pas mal de temps
          (Je dois avoir une bonne centaine d'utilsateur dont les + importants [les directeurs]
          Je dois dire que j'en suis relativement satisfait :
          Syncro (funambol) avec PocketPC - > au poil
          Syncro (funambol) avec Outlook - > au poil (mais il faut se contenter du minimum)
          Utilisation Calendrier -> Au poil [avec quelques bémols sur certains points ergonomiques (*) ]
          Utilisation Messagerie-> Au poil [fait sur mesure pour postfix/cyrusimapd/ldap, ce qui est le cas chez moi]
          Gestion des documents : la demande commence a se faire + pressante , mais là les outils sont qd même limités (**)

          (*) Courant Mai la nouvelle version 1.4 va sortir . Cette version améliore grandement les quelques problèmes ergonomiques.
          (**) En principe , ils ont prévu pour la version 1.6 (début 2008,je pense) de refondre totalement la gestion de documents (webdav peut être CIFS ..)

  • # Bounty ?

    Posté par  (Mastodon) . Évalué à 2.

    Si tu comptais l'implémenter quelque part, pourquoi ne proposes tu pas une bounty pour qui écrira les fonctionnalités qui te manquent ?

  • # Oui mais kolab ça marche

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

    Un serveur kolab c'est :
    _ simple à déployer
    _ simple à configurer
    _ simple à administrer
    _ léger
    _ ça marche nikel avec kontact
    _ ça marche nikel avec horde
    _ ça marche avec Outlook (via le truc proprio)
    _ le format est hyper simple [1]
    _ la protocole de base est imap
    _ les applications utilisés (postfix, openldap, cyrrus, sasl ...) on fait leurs preuves et sont toutes connues des geeks de par ici.

    A ma connaissance aucune autre solution n'a toutes ces qualitées.

    Alors mon sentiment, c'est qu'il manque peut-être plus des libkolab-connector en perl, python, php, java, C# ... pour faire des interfaces et des wrappers que le support de tel ou tel protocole.

    • [^] # Re: Oui mais kolab ça marche

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

      [1] http://kolab.org/doc/kolabformat-2.0rc1-html/index.html

      • [^] # Re: Oui mais kolab ça marche

        Posté par  . Évalué à 0.

        Kolab fait le partage de boite mail entre différents utilisateurs (Par exemple la secrétaire qui tappe et envoie les mails de son patron) ?

        • [^] # Re: Oui mais kolab ça marche

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

          Ca fonctionne avec les groupes. Mais il ne sagit pas de partage, mais de possibilité d'envoyé avec un certain compte mail.

        • [^] # Re: Oui mais kolab ça marche

          Posté par  . Évalué à 1.

          A priori oui. On peut partager son agenda et ses contacts perso. comme tout ca est stocké dans des répertoires IMAP, il n'y a pas de raison que le INBOX ne soit pas partagable.

          C'est Cyrus qui gere les ACLs :) par contre pour l'identité sous lequel le mail est envoyé, c'est le client qui doit gérer (identité multiples ?)

    • [^] # Re: Oui mais kolab ça marche

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

      C'est aussi :
      - Pas si simple a déployer : ca ne compile pas avec GCC 4 (qui date quand même...), donc faut que je mette GCC 3.4 sur ma machine (et binder a la mano gcc vers gcc3), et je n'aime pas foutre le bordel dans mon compilo
      - Je n'arrive pas a voir si je peux avoir Sunbird dessus (ca n'a pas l'air) (OK, c'est pas que la faute de Kolab, mais c'est un ensemble que je cherche...)
      - Horde n'est pas officiellement supporté (unstable), donc pas de webmail/webcalendar officiel pouvant se connecter à Kolab

      Pour le reste on est d'accord.
      C'est bien la conclusion du journal : énorme potentiel, mais il lui manque des choses importantes.

      • [^] # Re: Oui mais kolab ça marche

        Posté par  . Évalué à 2.

        Sunbird ne marche pas dessus, vu que Kolab ne supporte pas CalDAV (à part un hack immonde dans le wiki à oublier).

    • [^] # Re: Oui mais kolab ça marche

      Posté par  . Évalué à 2.

      Et sous MacOS, tu y accède comment ?

      Le parc est constitué de pas mal de Macs (d'où Sunbird en attendant iCal de 10.5).

Suivre le flux des commentaires

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