Empathy : l'avenir de la messagerie instantanée dans GNOME

Posté par  . Modéré par Nÿco.
Étiquettes :
0
2
août
2007
XMPP
Certains d'entre-vous ont certainement déjà essayé la branche télépathy de Gossip, le client Jabber libre pour GNOME. Cette branche n'est plus maintenue et pour une bonne raison : elle a donné naissance à Empathy.

Empathy se propose d'être une ensemble de widgets réutilisables pour la messagerie instantanée. Pour cela, il se base sur Telepathy (framework unifié de communication temps-réel sur le bureau) et Mission Control (une abstraction de Telepathy). L'interface est reprise de Gossip et notamment de la branche TELEPATHY de Gossip.

Le but principal est de permettre une intégration inégalée de la messagerie instantanée dans le bureau GNOME, comme par exemple avec le carnet d'adresses. Le futur est bien évidemment la VoIP, en témoigne la branche gossip-telepathy-voip développée par Raphaël Slinckx. Empathy est principalement constitué de deux bibliothèques : libempathy et libempathy-gtk. Empathy propose aussi un simple client de messagerie instantanée se basant sur ces deux bibliothèques.

Gossip est le client Jabber créé pour GNOME par Imendio à qui on doit aussi Blam!. Contrairement à Gossip, Empathy se base sur Mission Control (écrit par Nokia et libéré au printemps dernier) pour gérer les comptes, en plus de se baser sur Telepathy pour la transmission.

On peut se demander quelle place est laissée à Galago, pour gérer la présence des contacts. Toujours est-il que la problématique de la messagerie instantanée éclate, elle est découpée soigneusement et chaque composante reçoit sa solution : Telepathy, Mission Control et maintenant Empathy.

Le tout est déjà bien fonctionnel. Votre serviteur a pour sa part pu tester le discussion via Bonjour entre Empathy et iChat AV. De plus, le projet est actif avec notamment un projet Google Summer of Code 2007 ajoutant le support du transfert de fichier par Marco Barisione.

Dans un sens, le libre prend une longueur d'avance en terme d'interopérabilité et d'infrastructure. En revanche, il semble que le libre traine encore et toujours en terme de voix et vidéo (NdM : et de whizz ;).

Aller plus loin

  • # Soc

    Posté par  . Évalué à 9.

    A noter que, en plus du transfert de fichiers, plusieurs autres projets Summer of Code sont en réalisation:

    - l'intégration de la VOIP dans Jokosher : http://code.google.com/soc/2007/gnome/appinfo.html?csaid=964(...)

    - L'ajout de widgets pour la VOIP et video dans Empathy : http://code.google.com/soc/2007/gnome/appinfo.html?csaid=580(...)

    - Un connection manager utilisant libpurple: http://code.google.com/soc/2007/gaim/appinfo.html?csaid=D129(...)
    Ce dernier devrait permettre à Empathy (et n'importe quel autre client Telepathy) de supporter la multitude de protocoles actuellement implémentés dans Pidgin.
  • # XMPP / Empathy

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

    J'ai un peu de mal. Si je comprend bien ce que je lis Empathy et MC permettent d'avoir une abstraction pour envoyer des messages, les recevoir, les gérer, voir les présences, gérer les contacts, etc. Les logiciels vont pouvoir s'interfacer sur cette couche pour dialoguer au lieu de tout gérer eux même.

    Ca c'est bien, mais ça ne fait pas déjà un double emploi avec ? XMPP est pour moi déjà un protocole standardisé qui gère tout ça. Il aurait "suffit" de faire une sorte de proxy XMPP local qui forwarde aux différents serveurs (jabber, msn, autres). Les applications n'auront qu'à parler XMPP.

    Là j'ai l'impression qu'on refait encore une couche d'abstraction sans qu'elle apporte rien de plus que XMPP. Au lieu de dialoguer en XML/XMPP les applis vont dialoguer avec des structures en C avant d'être retraduits en XML/MSN/autre. Je ne suis pas certain du gain là.

    Quelqu'un pour m'éclairer ?
    • [^] # Re: XMPP / Empathy

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Il est plus simple de faire un "for m in client.message_queue:" que de devoir reparser le XML à la main.

      Le XML garantie une interopérabilité entre systèmes, mais il reste plus simple d'utiliser des librairies bien conçues pour coder simplement, au sein d'un même système.

      En plus, il n'est pas évident qu'un "proxy XMPP" soit la solution multi-usage, ceux qui utilisent les passerelles Jabber savent qu'il n'est pas évident que le plus petit dénominateur commun convienne à tout le monde...
      • [^] # Re: XMPP / Empathy

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

        > Il est plus simple de faire un "for m in client.message_queue:" que de
        > devoir reparser le XML à la main.

        Je le conçois, mais dans ce cas la solution peut être une libxmpp ou une libjabber, pas forcément un serveur complet avec son propre protocole.

        > En plus, il n'est pas évident qu'un "proxy XMPP" soit la solution
        > multi-usage, ceux qui utilisent les passerelles Jabber savent qu'il
        > n'est pas évident que le plus petit dénominateur commun convienne à
        > tout le monde...

        Empathy n'a pas l'air de changer quoi que ce soit à cette problématique. Il y a une méthode d'accès par fonctionnalité si j'ai bien compris. Donc on parle toujours d'avoir un dénominateur commun unique.
        • [^] # Re: XMPP / Empathy

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

          Utiliser xmpp pour faire du msn, ça implique de passer par une passerelle, ce qui pose divers problémes :

          1) il faut modifier le serveur, ou du moins, avoir un serveur qui fait tourner la passerelle, accesible depuis l'internet. En effet, tout passe par le serveur xmpp, il faut donc avoir un lien entre le serveur et la passerelle. Pas faisable si tu es derriére du nat.

          Exemple : je veut parler à quelqu'un avec qq, protocole populaire en chine. Avec empathy/telepathy, j'ai que à rajouter le manager qui va bien, et je peut.
          Avec l'approche passerelle, faut que je trouve une passerelle accessible, et si ça existe pas, je ne peut rien faire sur mon pc de simple pour la mettre en place. ( dans les 2 cas, pour le moment, ça n'existe pas )

          2) Le passage par le serveur et une passerelle implique d'oublier tout espoir de connexion p2p qui contourne le tout. Par exemple, comment ton client jabber va négocier et utiliser le transfert de fichier avec un client msn sans passerelle ? Et passer par la passerelle serait extrement couteux au niveau réseau dans la plupart des cas. Il ne faut pas oublier que la video passe aussi en direct.

          3) tout ne correspond pas directement aux concepts de jabber. par exemple, il suffit de voir les différences entre irc et les salons muc de jabber, notament la gestion du nickname ( 1 par salon sur jabber ), les avatars, les cctp, etc.
          • [^] # Re: XMPP / Empathy

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

            Pour le 1 je ne vois pas en quoi faire tourner une passerelle en local serait impossible ou même difficile. C'est à priori d'un niveau de difficulté équivalent à ce que font pidgin ou telepathy.

            Pour le 3 c'est une question de dénominateur commun. Telepathy va forcément rencontrer à moyen terme des problèmes similaires. Quand on met une couche d'abstraction on a toujours le risque de perdre des détails.

            Pour le 2, en considérant une passerelle locale (c'est à dire le même niveau d'abstraction/architecture que telepathy), je ne vois pas où est la difficulté en plus par rapport à ce que ferait telepathy.
            • [^] # Re: XMPP / Empathy

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

              Pour le 1, faut que le serveur puisse contacter la passerelle. donc il te faut une ip routable. Ou alors, tu te retrouves à avoir une techno différente de ce qui existe actuellement.

              Pour le 2, soit tu passe par le serveur ( ie technologie actuelle des passerelles ), soit tu utilise un truc différent ( et dans ce cas, c'est autant une invantion différente de xmpp que telepathy est actuellement différent )

              Pour le 3, la différence avec xmpp, c'est que c'est pris en compte dans la conception de telepathy, alors que jabber est pris de façon indépendante du reste du monde.
              • [^] # Re: XMPP / Empathy

                Posté par  . Évalué à 4.

                Pour le 1, faut que le serveur puisse contacter la passerelle. donc il te faut une ip routable.

                Heu, si serveur et passerelle sont sur la même machine, 127.0.0.1 me semble parfaitement "routable"...
                • [^] # Re: XMPP / Empathy

                  Posté par  . Évalué à 0.

                  Logiquement, une passerelle doit pouvoir être joignable par deux éléments (sinon, ça fait difficilement passerelle).

                  L'un des éléments est certes le serveur local, mais l'autre doit être le serveur correspondant au protocole externe (par exemple, messenger.hotmail.com). Donc il faut bien que tu aies une IP routable ou de la redirection de ports.
                  • [^] # Re: XMPP / Empathy

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

                    Non, une passerelle ne doit être joignable que par le serveur jabber.

                    Et c'est la passerelle qui va joindre le serveur du service externe (messenger.hotmail.com) comme le ferait un client normal.

                    En conclusion, si le serveur est local, la passerelle peut être locale.

                    Maintenant, reste à discuter de l'interêt d'avoir un serveur local sur une IP non routable
                • [^] # Re: XMPP / Empathy

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

                  Donc je récapitule : plutot que d'utiliser telepathy, on va
                  1) mettre en place un serveur xmpp en local
                  2) mettre en place des passeerelles local pour aller sur les réseaux fermés
                  3) mettre une passerelle jabber vers jabber pour aller vers le compte jabber principal
    • [^] # Re: XMPP / Empathy

      Posté par  . Évalué à 6.

      XMMP n'est pas la solution à tout (cfr les gateways).

      De plus, Telepathy offre une abstraction via D-Bus [1] ce qui permet:
      - un meilleur cloisonnement. Si ton connection manager MSN plante, ça fou pas en l'air tes autres connections (jabber, IRC, ...). C'est aussi un certain retour vers la philosophie Unix ("Do one job and do it well").
      - un partage des connections entre les processus
      - une indépendance de langage que ce soit coté client ou connection manager
      - une indépendance de licence (pas de linkage)

      [1] http://telepathy.freedesktop.org/spec.html
      • [^] # Re: XMPP / Empathy

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

        L'indépendance de licence et de langage elle existe justement déjà (et bien mieux) dans le principe d'échange xmpp.
        Le partage des connexions n'y est pas, il est vrai, mais xmpp permettant de gérer plusieurs connexions sur le même compte, je ne sais pas si c'est vraiment indispensable de partager la connexion (surtout si on peut mettre un proxy xmpp au milieu pour ne pas surcharger le serveur distant).
        Le cloisonnement, si je ne me trompe pas les passerelle jabber sont déjà indépendantes de ce côté là.

        Mais qu'on soit d'accord, je ne dis pas que XMPP est la solution à tout où que Empathy a son rôle à jouer. C'est juste que je ne vois pas dans la news, dans le site ou dans ta réponse la fonctionnalité clé que couvre Empathy et que ne couvrait pas déjà XMPP à la base.
        Mieux que ça même, je ne remettais pas en cause le bénéfice d'empathy, je demandais juste qu'on me le mette en lumière.
        • [^] # Re: XMPP / Empathy

          Posté par  . Évalué à 3.

          Si j'ai bien compris tes explications, tu voudrais que :
          - telepathy soit un serveur XMPP "light" avec passerelles & co
          - les applis soient clientes via empathy (qui correspondrait au libxmpp que tu cites ailleurs)

          Tu oublies juste qu'il y a déjà un existant qui s'appelle d-bus pour faire ce genre de "messagerie" entre applis locales et qu'il serait dommage de ne pas en profiter ou de réinventer la roue.
          A moins que tu proposes un "XMPP over DBus"...
          • [^] # Re: XMPP / Empathy

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

            > Si j'ai bien compris tes explications

            Oui, ça correspond à quelque chose du genre.

            > Tu oublies juste qu'il y a déjà un existant qui s'appelle d-bus pour faire
            > ce genre de "messagerie" entre applis locales et qu'il serait
            > dommage de ne pas en profiter ou de réinventer la roue.

            Certes, mais entre utiliser un socket tcp/ip là où on pourrait utiliser dbus (ce que j'imaginais) et avoir à réimplémenter entièrement un protocole pour la gestion de la présence, pour les messages instantannés, pour la gestion des comptes, pour la gestion des contacts (ce qui a été fait ou qui est fait dans telepathy si j'ai bien compris) ...

            J'ai l'impression que la seconde option est bien plus proche du "réinventer la roue" que la première. Maintenant il est possible/probable qu'il y ait quelque chose que je n'ai pas vu qui inverse la balance.
            • [^] # Re: XMPP / Empathy

              Posté par  . Évalué à 7.

              avoir à réimplémenter entièrement un protocole pour la gestion de la présence, pour les messages instantannés, pour la gestion des comptes, pour la gestion des contacts

              Ca, c'est plutot Mission Control qui s'en occupe si j'ai bien suivi.

              Maintenant il est possible/probable qu'il y ait quelque chose que je n'ai pas vu qui inverse la balance.

              Comme par exemple le fait que tout ca se retrouve centralisé, et que ca devrait simplifier énormément la gestion de XMPP par des applis comme Abiword, Inkscape, Evolution ou Gnome-game,qui pourront simplement demander a Mission Control qui est disponible, d'ouvrir une connexion vers un des contacts, ou de récupérer la vcard de Machin qui vient de la mettre a jour ; au lieu de devoir chacun, individuellement, se gérer login/password/serveur, l'ouverture de connexion, et toutes les choses chiantes qui vont avec.
              • [^] # Re: XMPP / Empathy

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

                Ah merci je commence enfin à entrevoir l'intérêt de ce truc. Perso j'ai rien compris à la dépêche. L'exemple du carnet d'adresse était pas super clair pour moi.
            • [^] # Re: XMPP / Empathy

              Posté par  . Évalué à 2.

              Dis moi si j'interprete mal, mais en gros, tu compares
              1) devoir définir et mettre en place une spec dbus comme telepathy (implémentant les renseignements de présence, etc...)
              2) implémenter une sorte de "XMPP over DBus" profitant du fait que XMPP soit fait pour gérer ce type d'infos.

              Ta solution 2 m'a pas l'air très propre.
              Sans compter qu'il y a les infos spécifiques à chaque protocole que tu auras du mal à faire passer (a p-ê moins de bidouiller le xmpp qui circulera en interne, là j'y connais pas grand chose...)

              Et vu les modifs de comportements à faire par rapport à un serveur xmpp "classique", autant partir propre from scratch.
              Rien que le transfert de fichier msn par exemple, tu dois modifier ton serveur pour que
              -soit telepathy prenne le fichier direct (contrairement au XMPP "externe" donc)
              -soit faire une passerelle entre XMPP (interne) et msn
              + faire passer d'éventuelles infos spécifiques à MSN d'une manière où d'une autre (mais comment ?)

              Vu les modifs à faire + l'interpretation supplémentaire au niveau de l'appli cliente (en gros, une libxmpp pour le "over dbus") ca ne me parait pas plus simple au final.
      • [^] # Re: XMPP / Empathy

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

        > - une indépendance de licence (pas de linkage)

        Ce n'est pas la première fois que je vois cet argument cité en faveur d'un ou l'autre service D-Bus.

        Je trouve ça complètement stupide. C'est un contournement stupide de la GPL.

        Si ils veulent autoriser le propriétaire, ils n'ont qu'a coder une bibliothèque avec une licence adéquate (par exemple LGPL)
  • # Et ç'est déja utilisé

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

    Il y a deja d'autres logiciels qui prévoit de se baser dessus :
    - Soylent ( http://live.gnome.org/Soylent ), cf http://treitter.livejournal.com/1604.html. Soylent est un gestionnaire de personnes, un peu comme nautilus pour le carnet d'addresse.

    - un plugin pour epiphany ( http://blog.senko.net/2007/07/19/emphatic-epiphany/ ), pour envoyer un lien directement à un client

    - Jokosher, ou on pourras à terme faire des interviews de gens avec la de la voip , via le réseau ( http://blog.mikeasoft.com/2007/05/07/jokosher-soc/ )

    Et je suis sur qu'il y a des tas d'idées à implementer ( file sharing sur le reseau via telepathy-salut, etc , etc ).
    • [^] # Re: Et ç'est déja utilisé

      Posté par  . Évalué à 2.

      L'Edition collaborative dans Abiword et Inkscape devraient utiliser Empathy. Une autre utilisation c'est le gnome-games, au lieu de l'actuelle hideuse fenêtre pour jouer à snake en réseau on pourrait simplement avoir une liste des contacts online et jouer avec eux.
    • [^] # Re: Et ç'est déja utilisé

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


      Soylent est un gestionnaire de personnes

      J'espére qu'il n'est pas trop vert, sinon ce n'est pas le genre de gestion de personnes qui m'intéresse.

      ->[]
      • [^] # Re: Et c'est déjà utilisé

        Posté par  . Évalué à 4.

        Mais si voyons : place aux jeunes !

        Tiens ? d’où vient cette musique ? c’est Vivaldi ? Oh, les jolies images champêtres…
  • # Et en pratique...

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

    Un plugin utilisant empathy a été développé pour le navigateur epiphany [1]. Il est très sommaire pour le moment, mais ça permet d'avoir une idée de ce qu'il est possible de faire.

    En tous cas, c'est très prometteur et on a des chances de voir l'adoption d'empathy dans de nombreuses applications assez rapidement.

    [1] http://blog.senko.net/2007/07/19/emphatic-epiphany/
  • # intéropérabilité?

    Posté par  . Évalué à 8.

    KDE permet lui aussi une telle chose, en liant Kopete avec Kontacts, Kmail... Ce qui est très pratique, je trouve, pour centraliser les infos sur ses contacts.
    Alors, loin de moi l'idée de critiquer le fait que chaque bureau fasse sa petite appli, ça permet le choix (on ne va pas revenir sur ces arguments longuement débattus).
    Cependant, je me demande quand même s'il n'y a pas une certaine redondance, redondance qui aurait donc pu être factorisée (au sein d'un projet freedesktop par ex.).
    Parce que ce que je crains, c'est qu'une appli KDE ne soit pas capable de se synchroniser avec le bureau Gnome (oui, certains aiment mixer les 2, et utiliser les meilleures applis de chaque bureau), sauf à récrire/rajouter le support d'une nouvelle couche...

    Alors qu'un éventuel projet commun à tous les bureaux (ne nous limitons pas à Gnome et KDE sans raison) aurait sans doute évité que plusieurs projets réinventent la roue "inutilement" (le terme est peut-être déplacé).
    • [^] # Re: intéropérabilité?

      Posté par  . Évalué à 7.

      Telepathy est un projet fd.o et MissionControl est entrain d'être standardisé (cfr telepathy's ML). Il y a même déjà un plugin kopette pour ajouter le support Telepathy, mais je ne sais pas où ça en est.
    • [^] # Re: intéropérabilité?

      Posté par  . Évalué à 7.

      C'est l'un des intérêts de Telepathy, mais c'est complètement éclipsé dans la dépêche.
    • [^] # Re: intéropérabilité?

      Posté par  . Évalué à 7.

      100% d'accord sur la partie que les bureaux devraient pouvoir se changer sans tout redefinir. L'exemple le plus flagrant sont les mails et les messageries instantanees.

      Les mails il faut redefenir a chaque fois les caracteristiques si tu veux tester un nouveau mailer, pire tu dois transferer tes mails dans tel ou tel format et tel ou tel place. Thunderbird mets ses mails dans .mozilla/thunderbird/1323mweq1231/Mail/... tandis que kmail les mets dans .kde/share/apps/kmail/mail/....
      c'est absolument pas pratique de passer de l'un a l'autre et pire il y a des risques de pertes dans ce genre de cas du coup meme si un de ces mailer (ou encore un autre) devient nettement mieux et a des killers features, l'utilisateur restera sur l'ancien a cause de ca.
      • [^] # Re: intéropérabilité?

        Posté par  . Évalué à 5.

        Akonadi, la nouvelle base pour KDEpim 4, veut régler ce problème. Mais faut que les autres logiciels suivent... ce qui est indépendant de la volonté de KDE. (Mailody et KMail utilisent déjà Akonadi je crois)
        • [^] # Re: intéropérabilité?

          Posté par  . Évalué à 4.

          Ca a l'air très bien pensé et je ne doute pas que les développeurs KDE coderont quelque chose de nickel. Par contre je ne suis pas du tout d'accord avec toi, les logiciels ne vont pas "suivre" tout gentiment même si c'est techniquement la solution parfaite, il y a énormément de travail de communication à faire et ça doit se jouer chez Freedesktop.org avec une participation exemplaire de KDE... Si je peux aider me le dire (cf mon autre commentaire).
  • # Et KDE...

    Posté par  . Évalué à 10.

    Decibel, l'un des pilliers de KDE4, utilise Telepathy.
    À terme, de nombreuses applications devraient l'utiliser pour faire du travail collaboratif par exemple.
    Cf. http://dot.kde.org/1170892771/ et http://dot.kde.org/1171659655/
  • # Carnet d'adresses Gnome

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

    En parlant de contacts et de carnet d'adresse, c'est quoi le carnet d'adresses pour un environnement Gnome aujourd'hui ?

    A une époque il y avait gnome-pim, mais c'est mort il me semble.
    Y'a bien Evolution qui fournit tout un basard, mais j'aime pas Evolution car c'est une application intégrant plein de fonctions et je préfère les petites applications dédiées.

    De plus, je me dit qu'en 2007, il doit bien y avoir une super appli/framework Gnome qui gère les contacts et fournit des services aux autres applis du bureau. Par exemple, j'imagine que pidgin et Ekiga peuvent/pourraient aller piocher leurs carnet d'adresse dans un truc central, plutôt que chacun son carnet d'adresse. Ce carnet central serait aussi utilisé par Claws-mail ou Thunderbird pour trouver les adresses e-mail.

    Merci d'avance pour toutes vos infos.
    • [^] # Re: Carnet d'adresses Gnome

      Posté par  . Évalué à 4.

      Le framework GNOME pour gérer les contacts et le calendrier c'est E-D-S (Evolution Data Server) qui peut tourner indépendamment de Evolution. D'ailleurs OpenedHand a développé la suite pimlico (dates, contacts, tasks et Sync) en s'appuyant sur E-D-S et développe de celui-ci une version "lite" pour l'embarqué.
      http://pimlico-project.org/index.html
      Quant à l'appli, Soylent est proche de ce que tu cherches et fais même plus.
      http://treitter.livejournal.com/1046.html
      • [^] # Re: Carnet d'adresses Gnome

        Posté par  . Évalué à 6.

        mouais...
        EDS c'est : "The data server, called "Evolution Data Server" is responsible for managing mail, calendar, addressbook, tasks and memo information."

        ça fait pas un peu trop pour un seul homme? En gros c'est l'inverse de la philosophie d'Empathy, non?

        Pimlico et Soylent ne font pas parti de Gnome, non? En tout cas je ne les ai pas chez moi...

        Bref je cherche toujours l'équivalent de Kontact et de l'ex Gnome-pim...

        Actuellement j'utilise jpilot car Sylpheed sait s'interfacer dessus.
        • [^] # Re: Carnet d'adresses Gnome

          Posté par  . Évalué à 2.

          EDS c'est grossièrement une base de données (la partie spécifique à la gestion de contacts c'est libebook) et un service offrant une interface à divers programmes: Evolution, Gaim, Planner, gnome clock etc ...
          > En gros c'est l'inverse de la philosophie d'Empathy, non?
          Je comprends pas vraiment. EDS, telepathy et empathy sont complémentaires et non pas un opposition. EDS c'est la base de données stockant les contacts, Telepathy s'occupe de la partie communication et se synchronise à EDS via D-Bus pour accèder et gérer les contacts. Quant à Empathy c'est un jeu de widgets pour offrir les fonctionnalités de messagerie instantannés aux applications GNOME sans devoir se taper l'API de Telepathy.

          Effectivement, GNOME ne propose pas à l'heure actuelle un équivalent à Kontact.
          Pimlico est destiné à l'embarqué (N770/N800 par exemple), néanmoins la plupart des distributions fournissent déjà Contacts et Dates (du moins la mienne), au pire, ils sont très simple à empaqueter.
          • [^] # Re: Carnet d'adresses Gnome

            Posté par  . Évalué à 2.

            > En gros c'est l'inverse de la philosophie d'Empathy, non?
            Je comprends pas vraiment.


            Je faisais allusion au message de cassidy à 12h02:

            Sinon ce que je ne sais pas faire avec gnome autrement qu'avec jpilot c'est partager les données de mon vieux palm 3 avec sylpheed, etc.

            Un truc qui m'énerve profondément c'est que par exemple quand tu ouvres le calendrier de l'applet horloge de Gnome et que tu double cliques sur une date et bien il commence à te lancer Evolution et te demande de configurer ta messagerie!!! C'est quoi le rapport avec le fait de cliquer sur date????
            • [^] # Re: Carnet d'adresses Gnome

              Posté par  . Évalué à 2.

              Mon message initiale parlait de la philosophie de Telepathy.

              Le but d'empathy est d'intégrer joliment Telepathy dans GNOME. Cela passe donc par l'utilisation de eds afin d'offrir une expérience optimale à l'utilisateur (récupérer les infos d'un contact via sa vcard jabber et la mettre dans l'address book, automatiquement configurer tes comptes d'IM que tu as introduit dans gnome-about-me, voir que machin@hotmail.com et truc@jabber.org sont la même personne car ils sont dans la même entrée de ton address book... ce genre de choses).

              Après on peut discuter des choix de design de eds en lui même, mais bon, c'est pas trop le sujet. Et puis, au final, eds n'est jamais qu'une DB utilisée par différentes applications GNOME (Evolution, Contacts, Dates, gnome-about-me et, bientôt, Empathy).
              • [^] # Re: Carnet d'adresses Gnome

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

                >différentes applications GNOME (Evolution, Contacts, Dates, gnome-about-me et, bientôt, Empathy).

                Ekiga aussi non ?
                • [^] # Re: Carnet d'adresses Gnome

                  Posté par  . Évalué à 2.

                  Tout à fait.

                  À noter que lorsque le support de la video/voip sera terminé (cfr Soc), Empathy sera également capable de faire de la vidéo conférence SIP via telepathy-sofiasip, le connection manager récemment libéré par Nokia (merci à eux).
          • [^] # Re: Carnet d'adresses Gnome

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

            C'est bien ce qu'il me semblait : y'a plus d'équivalent gnome-pim. J'allais passer à gpe-contacts et consort, mais pimlico semble bien. Je vais essayer.

            Merci du tuyau.
          • [^] # Re: Carnet d'adresses Gnome

            Posté par  . Évalué à 3.

            EDS est lié à Gnome et pas freedesktop.org, non ?

            Je trouve que c'est ça le problème avec EDS (et avec le framework contacts de KDE KDEPIM aussi je pense).

            C'est pas très sexy peut-être comme projet mais c'est quand même fondamental ! J'aimerais un seul carnet d'adresses sous Linux qui serve toutes les applis, le LDAP c'est lourd et pas trop fait pour ça je suppose.

            Le "Desktop linux" aurait vraiment besoin d'un projet fédérateur de base de données PIM. Sur Freedesktop.org on a Galago qui tente de rattrapper le coup pour les contacts en piochant dans les applis compatibles. On a Opensync pour la synchro. C'est tout...

            Je devance les "ben t'as qu'à le coder toi-même", faire une énième implantation de ce qu'à fait Palm il y a des années (ou un autre avant, je ne sais pas), non merci, ça existe déjà en beaucoup mieux que je ne saurai faire. Par contre si quelqu'un sait comment je peux être utile... poster sur les mailing-lists KDE, Gnome et Freedesktop ?
            • [^] # Re: Carnet d'adresses Gnome

              Posté par  . Évalué à 2.

              J'aimerais un seul carnet d'adresses sous Linux qui serve toutes les applis


              Il y a cette approche, ou l'approche syncml [http://fr.wikipedia.org/wiki/SyncML] qui permet de synchroniser les différentes sources par un protocole normalisé, qui du coup peuvent être ni Gnome ni KDE mais aussi bien un téléphone portable qu'un PDA, ou qu'un poste sous Windows.

              Idéalement, ca devrait même pouvoir synchroniser le répertoire de mon téléphone fixe :-)

              Et perso, moi, c'est ça que je voudrais.

              Enfin, on s'éloigne du sujet, Empathy ne fait pas que de la synchro de contact, mais aussi bien plus, et même plutôt autre chose. :-)
              • [^] # Re: Carnet d'adresses Gnome

                Posté par  . Évalué à 2.

                Ce n'est pas incompatible ! :-)

                Admettons que tu utilises syncml pour synchroniser ton téléphone portable, ton PDA, et un poste Windows, ce n'est pas une raison pour avoir ces données enregistrées en triple exemplaire sur ton poste linux car tu aimes souvent changer de bureau!!
                • [^] # Re: Carnet d'adresses Gnome

                  Posté par  . Évalué à 1.

                  Entièrement d'accord, pour des raisons de sauvegarde par exemple. Aussi, mais je ne me suis sûrement pas assez penché sur Opensync/SyncML, la synchronisation c'est compliqué. Par exemple sur mon portable si je change le numéro de quelqu'un, mais que sur mon PC j'ai changé l'adresse de la personne, je ne sais pas comment fusionner les modifications de façon sûre. Une seule base "source" serait plus simple à gérer, en exportant après vers les autres plateformes. Sinon oui, on s'éloigne du sujet initial c'est vrai, mais est-ce si grave ?
            • [^] # Re: Carnet d'adresses Gnome

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


              Le "Desktop linux" aurait vraiment besoin d'un projet fédérateur de base de données PIM. Sur Freedesktop.org on a Galago qui tente de rattrapper le coup pour les contacts en piochant dans les applis compatibles. On a Opensync pour la synchro. C'est tout...


              Je ne suis pas vraiment au fait des projets de FreeDesktop.org. Par contre, j'avais découvert le projet Portland : http://portland.freedesktop.org/wiki/TaskAddressbook
              Est-il implémenté quelque part ?
        • [^] # Re: Carnet d'adresses Gnome

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

          > Bref je cherche toujours l'équivalent de Kontact

          Hum, l'équivalent de kontact c'est evolution. kontact c'est l'aggregation de kmail, korganizer, kaddressbook, k........, kpim.
        • [^] # Re: Carnet d'adresses Gnome

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

          "The data server, called "Evolution Data Server" is responsible for managing mail, calendar, addressbook, tasks and memo information"
          J'ai cru aussi, mais nan, EDS ne gère pas les mails, Evolution les gère à part. (Ce qui est un peu con con question unification à mon goût).
          • [^] # Re: Carnet d'adresses Gnome

            Posté par  . Évalué à 2.

            Pour les mails il y a déjà mbox et maildir. Le problème est chaque client crée ses propres boîtes mail.

            Ca sera peut-être un jour résolu par Freedesktop.org qui a des spécifications de noms de répertoires pour certains éléments comme la musique, les photos : http://www.freedesktop.org/wiki/Specifications/common-user-d(...)
            Mais rien encore pour les mails. Et puis ça n'a pas l'air d'évoluer très vite...

            Moi j'ai mis un serveur imap sur mes 2 machines de bureau et c'est très bien comme ça... je change de client mail quand je veux (sauf pour les contacts comme je l'ai déjà dit).
        • [^] # Re: Carnet d'adresses Gnome

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

          En fait, je fais comme ça aussi. Mais je trouve que ce n'est pas très "sexy" comme solution. Et puis je voudrais abandonner sylpheed sur mon desktop pour Thunderbird.

          Et vendre mon palm IIIxe (quelqu'un en veux, c'est pas cher :-))
  • # Essai de neurones

    Posté par  . Évalué à 10.

    Bon, j'ai pas tout compris comme d'habitude (ben oui, tout le monde n'est pas programmeur ni même programmeur amateur!!), alors je vais poser des questions qui seront peut-être stupides mais tant pis:
    Prenons un projet de client jabber au pif (non, aucun projet à ma connaissance ne s'appelle "au pif", c'est pour dire, je sais pas moi disons gajim, aller!)

    - est-ce que, si gajim implémente un truc qui va bien avec les machins décrits ci-dessus, on pourra enfin utiliser un seul gestionnaire de contacts (de notre choix, avec des applis/front-end changeables à volonté) pour, donc, gajim, pidgin (si je veux j'utilise plusieurs clients IM!), mon client mail préféré, et tout les applis qui le voudraient comme on a dit au-dessus?

    - pour le cas jabber, par exemple, les contacts ne sont pas stockés en local, mais est-ce que ce genre de trucs pourrait par exemple utiliser aussi bien des infos locales qu'à distance de façon transparente? (genre j'ai des contacts sur un serveur jabber, d'autres en local, et d'autres sur un compte webmail quelconque, et tout apparaît ensemble sans problème -tant que je suis connecté bien sûr, suis pas si bête-)

    - tous ces trucs sont-ils facilement intégrables dans d'autres desktop si les devs de ces desktop le décident (tout le monde n'a pas le même nombre de développeurs que kde et gnome, et je pense en particulier à xfce et e17)? parce que un truc "indépendant du bureau" mais "implémenté sur deux bureaux" parce que ça représente 5ans-hommes de boulot, ça va rapidement limiter l'intérêt de la portabilité (sauf si on aime lancer des applis gnome sur kde et vice-versa)

    Si la totalité de ces questions sont vraiment stupides, vous pouvez allégrement moinsser avec mon approbation: si mon post est caché je passerai moins pour un blaireau auprès des suivants! :D
  • # Bon client IM actuel ?

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

    A ce propos, il faut utiliser quoi comme client IM générique ? Je viens de m'acheter un portable collé sous ubuntu, et j'ai remis gaim par habitude, mais mon dieu que c'est laid comparé à Adium... :(

    Un truc sexy à-la Adium, ça existe toujours pas ?

Suivre le flux des commentaires

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