Lucane Groupware 0.7 stable est disponible

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
24
mai
2004
Communauté
La nouvelle version de Lucane à été publiée le 17 mai.

Les ajouts majeurs concernent des évolutions du calendrier (vue par semaine, export PDF, ...), l'ajout d'une application d'audioconférence utilisant le codec speex (NdM : spécialisé voix), pas mal de corrections de bugs et des ajouts cosmétiques.

À noter : depuis la publication de l'appel à contribution dans Linux Magazine, une traduction du site web a été effectuée.

NdM : Lucane est une plateforme collaborative écrite en java et publiée sous LGPL. C'est un des rares groupwares qui ne soit pas en environnement web.

Aller plus loin

  • # Comparé aux autres ?

    Posté par  . Évalué à 8.

    Ca vaut quoi par rapport aux Kolab et autres OpenGroupware.org ?

    Je suis sur le point d'installer un système de ce genre dans ma boite (en logiciel libre bien sûr) et je ne sais pas trop lequel est le plus mature et le plus complet.

    Je voudrais surtout que ce soit pleinement utilisable sous Win comme sous Linux, sans plugin propriétaire.
    • [^] # Re: Comparé aux autres ?

      Posté par  . Évalué à -1.

      la JVM peut facilement être assimilée à un plugin propriétaire.
      • [^] # Re: Comparé aux autres ?

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

        N'importe quoi.... ce n'est pas un plugin et certaines JVM sont libres...
        Donc assimilé n'est pas un mot qui convient du tout.

        http://about.me/straumat

        • [^] # Re: Comparé aux autres ?

          Posté par  . Évalué à 2.

          si, mais il faut réfléchir un tout petit peu.

          allez, au pif : les classes java de base, ce qui fait le fichier rt.jar, tout ce qui rentre dans java.* et ceci inclut java2d aka Swing, les JFC, c'est libre ? c'est utilisable sans avoir à installer la JVM de Sun et en avoir accepté la licence et les conditions d'emploi ?

          oui, des implémentations compatibles au niveau de l'API existent ou sont en projet. mais ce n'est même pas sûr qu'on ait le droit de faire une implémentation libre de Swing/JFC sans devoir respecter certains points comme ne pas fournir de look&feel Windows ou Mac sous *nix, ou de look Apple depuis Windows.


          je ne dis pas ici que Java c'est mal, je dis juste qu'il y aura les mêmes contraintes, légales sinon techniques, qu'avec .NET et Mono.
          • [^] # Re: Comparé aux autres ?

            Posté par  . Évalué à 0.

            Pourquoi fournir un Look and Feed Windows ou Mac sous Linux ?
            Cela ne fait partie de l'API standard !
            Je ne vois donc pas le problème.
          • [^] # Re: Comparé aux autres ?

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

            si, mais il faut réfléchir un tout petit peu.
            Oui, réfléchissons ensemble, encore une fois, sur le fait que le langage Java peut être utilisé dans un environnement libre.

            allez, au pif : les classes java de base, ce qui fait le fichier rt.jar, tout ce qui rentre dans java.* et ceci inclut java2d aka Swing, les JFC, c'est libre ?

            C'est défini intégralement par le Java Community Process (JCP) qui est une instance distincte de Sun. Celui-ci définit pour les versions à venir du langage et de la plateforme Java le contenu et la manière dont ce sera réalisé. N'importe qui peut se présenter pour participer à des JSR (Java specif... je-sais-plus-quoi). Ces JSR définissent chacune une fonctionnalité qui sera intégrée dans la prochaine version de la JVM. Par exemple, les JSR de Java 1.5 (que j'appelerais personnellement Java3) définissent la généricité (argl), les annotations (un truc formidablement génial) l'autoboxing des types primitifs (on se demande pourquoi ça arrive seulement maintenant), j'en passe et des meilleures.
            Une fois les JSR adoptées, les fournisseurs de JVM divers (dont fait partie Sun) doivent implémenter celles-ci pour se voir reconnus fabricants de JVM.

            c'est utilisable sans avoir à installer la JVM de Sun et en avoir accepté la licence et les conditions d'emploi ?

            Oui, grâce aux JVM libres, ou en utilisant une JVM d'un autre fabricant de Logiciel (BEA, IBM)

            oui, des implémentations compatibles au niveau de l'API existent ou sont en projet. mais ce n'est même pas sûr qu'on ait le droit de faire une implémentation libre de Swing/JFC

            Bien sûr que si, ces classes sont une partie des APIs Java. En tant que telles, si les implémentations fournies dans la JVM sont la propriété de Sun, on est toutefois libre d'en faire d'autres.

            sans devoir respecter certains points comme ne pas fournir de look&feel Windows ou Mac sous *nix, ou de look Apple depuis Windows.

            Tu dis quand même un peu n'importe quoi. Les restrictions de look'n'feel ne sont pas le fait de Sun, mais de Microsoft et d'Apple qui ne souhaitent pas (ce que je peux comprendre) voir leur travail utilisé sans leur accord sur un système d'exploitation concurrent.
            De la même manière, le fait que le look'n'feel Metal ne soit pas utilisable ne me dérange plas plus que ça.

            je ne dis pas ici que Java c'est mal, je dis juste qu'il y aura les mêmes contraintes, légales sinon techniques, qu'avec .NET et Mono.

            Pas du tout.
            • [^] # Re: Comparé aux autres ?

              Posté par  . Évalué à 2.

              je connais le JCP, et les JSR, merci. inutile de dire que ça ne concerne que les versions récentes et futures de Java. (1.4 et au delà, à vue de nez).

              mon point est qu'il n'est pas possible d'utiliser des JVMs libres avec les fichiers rt.jar de Sun ou d'autres JVMs sans respecter la licence de ces dernieres, en recopiant simplement les bons fichiers comme certains media players le font pour utiliser des codecs propriétaires.


              >> sans devoir respecter certains points comme ne pas fournir de
              >> look&feel Windows ou Mac sous *nix, ou de look Apple depuis
              >> Windows.

              > Tu dis quand même un peu n'importe quoi. Les restrictions de
              > look'n'feel ne sont pas le fait de Sun, mais de Microsoft et d'Apple
              > qui ne souhaitent pas (ce que je peux comprendre) voir leur
              > travail utilisé sans leur accord sur un système d'exploitation
              > concurrent.

              euh, si. ce n'est pas Apple ou Microsoft qui codent et distribuent les JVMs de Sun, c'est Sun.


              J'ai personnellement discuté en 1999 avec un des gus de la Swing Team à ce sujet, sur le thème "les loupes sont moches" (pour les JTree de l'époque) alors que des triangles étaient envisagés, puis furent abandonnés. il m'a explicitement dit que c'était le service juridique de Sun qui a décidé ça pour éviter les ennuis, ces triangles étant "ceux" du Mac OS de l'époque.

              mais avec le bon argument -Dqqchose=1 en ligne de commande, on pouvait faire apparaitre une application Swing avec un look Windows ou Mac OS sous Solaris. ce n'était pas un problème technique, juste de propriété intellectuelle et morale sur le look&feel d'une plateforme, on va dire.


              bref. je maintiens que, pour Mono/.NET comme pour Java, un gros interet pour le développeur est la bibliothèque de code existant, et que ce qui est actuellement disponible n'est pas forcément libre ou utilisable sans aucun danger à long terme.
    • [^] # Re: Comparé aux autres ?

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

      je suppose que ca depends de votre besoin... cette page peut donner des pistes, mais elle est pas complete (si vous avez des infos supplémentaires, je suis preneur) :

      http://www.lucane.org/FR/groupware/documentation/general/comparison(...)

      en gros ce qu'il en ressort :
      * pour mail/calendrier/choses a faire, si tu as des besoins poussés (délégation, etc...), sans doute que kolab & OGo font mieux l'affaire.

      * pour le reste, les autres font simplement l'impasse, donc on doit sans doute faire mieux ;)

      par exemple, la on est en train de bosser sur le dessin partagé, et c'est typiquement un truc que tu trouveras pas dans OGo.
      • [^] # Re: Comparé aux autres ?

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

        je vois dans cette page que le carnet d'adresse est marqué "planifié" pour Lucane, ça veut dire qu'il n'y a pas encore de carnet d'adresse centralisé ? c'est plutôt rédhibitoire pour l'instant non ?
        • [^] # Re: Comparé aux autres ?

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

          c'est de la que vient le "ca depends des besoins" ;)
          par exemple kolab n'a pas de messagerie instantanée, ni de forum, ni de partage de fichiers (reprennez moi si je me plante, ca me semble gros quand même, ca).

          Je veux pas défendre mon bout de gras a tout prix, c'est juste qu'on a pas les mêmes critères de sélections, si tu as un grand besoin de carnet d'adresse, laisse tomber lucane pour le moment...
    • [^] # Une alternative à venir peut être ...

      Posté par  . Évalué à 5.

      Un client libre, multiplateforme pour Kolab (et OGo à venir) : Aethera
      http://www.atolcd.com/article147.html(...)

      M
  • # et pour les particuliers ?

    Posté par  . Évalué à 1.

    Bonjour.

    A part Yahoo, je ne connais aucune société proposant un "groupware" (très limité certes, mais qui répond tout de même à un réel besoin) en direction du particulier.

    Un tel service existe-t-il, ou va-t-il exister sous peu ?

    Grosso modo, il me faudrait :

    - un webmail avec gestion d'identités multiples, filtres "simples d'usage" contre le spam (regexp en option),
    - un carnet d'adresse, avec import/export/concaténation dans différents formats,
    - un agenda avec possibilité de partage et restrictions d'accès "fines" par utilisateur,
    - un gestionnaire de tâches avec rappels, classements, etc.
    - la synchro avec un palm (sous Windows, Linux et OSX),
    - tout en HTTPS,
    - pas de pub,
    - possibilité d'utiliser son propre nom de domaine (au moins dans les entêtes),

    Si en plus il y a possibilité d'avoir un accès à Usenet, avec un minimum de fonctions pratiques (mise en évidence des réponses ses propres articles, suivi de fil de discussion, sauvegarde des messages, etc.), ce serait le bonheur.

    Bref, un peu plus que ce que proposent le palm desktop, Yahoo et Google réunis, et le tout en ligne.

    Et je suis loin d'être le seul à attendre ce genre d'offre...
    • [^] # Re: et pour les particuliers ?

      Posté par  . Évalué à 0.

      et qui fait le café ? ;)

      sérieusement je vois pas comment tu peux faire la synchro avec un palm depuis une page web o.O

      enfin faudra d'abord que ca existe et puis après tu pourras esperer que quelqu'un en propose l'hebergement
      • [^] # Re: et pour les particuliers ?

        Posté par  . Évalué à 1.

        En fait pas avec du "web-php", mais avec des serveurs d'applis genre tomcat ou jboss si. Mais il faut au moins un navigateur avec java .... :(
        • [^] # Re: et pour les particuliers ?

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

          euh, j'ai du mal a voir le rapport entre la technologie utilisée sur le serveur et le fait de se connecter a un palm coté client, c'est normal ?
          • [^] # Re: et pour les particuliers ?

            Posté par  . Évalué à 1.

            En fait le principe est qu'avec les servers d'appli, ton navigateur (grace au java) se comporte comme une interface de logiciel, et peut communiquer avec ton matériel par exemple, alors que le javascript, ou toutes les technologies "coté server" en sont incapables.

            Le server d'appli, ca sert a centraliser le traitement, mais aussi a offrir plus de possibilités au client. Exemple : menu contextuel de l'appli alors que tu es dans un navigateur web, au lieu du "afficher la source" tu peux avoir un "palm synchro".

            A noter qu'on peux rajouter du java a petite dose meme quand c'est un groupware (par exemple) en php, mais ca reste sporadique.
  • # je répète

    Posté par  . Évalué à -1.

    lucane sapu

Suivre le flux des commentaires

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