C'est ce que fait Telepathy mais perso je n'ai pas bien vu l'intérêt.
- Au lieu que chaque appli utilise une lib jabber, chaque appli va utiliser dbus avec une api ou un protocole propre à ton serveur local. Je ne vois pas bien où on gagne en simplicité.
- Le fait d'avoir un proxy local toujours "up" avec plein de clients revient à refaire en local l'architecture de jabber : Le serveur Jabber sait déjà gérer les événements quand tu n'es pas connecté et te les renvoyer plus tard, pas besoin d'avoir un proxy local "toujours connecté" qui redispatche. De même ton serveur sait déjà gérer des clients multiples, pas besoin d'un proxy local là non plus.
Le seul gain est celui que tu donnes, pouvoir cliquer sur le roaster d'une appli pour que ce soit une autre qui ouvre la fenetre de discussion. En pratique j'ai du mal à voir l'intérêt que ça aurait mais peu importe : ça va nécessiter de développer un mini protocole pour savoir passer un truc d'une appli à l'autre, ou dire à laquelle on destine quoi. Au final ça aurait pu être fait en n'implémentant que la couche dbus sur tes applications, que l'application qui gère le roaster sache envoyer un message "ouvre une conversation sur X" à celle qui gère les discussions. Chacun peut garder sa connexion directe au serveur jabber, tu n'as pas besoin d'avoir un proxy local jabber pour ça.
Non parce que à force tu vas te rendre compte que ça serait même méga génial que ton petit proxy dbus puisse aussi converser avec une appli distante sur ton NAS par exemple. Là tu vas ouvrir ton proxy "local" au réseau. Au final tu auras juste recréé un nouveau serveur jabber, ou plutot un proxy.
# Oui mais
Posté par Éric (site web personnel) . En réponse au journal SàT: un client jabber (et oui, encore !). Évalué à 1.
- Au lieu que chaque appli utilise une lib jabber, chaque appli va utiliser dbus avec une api ou un protocole propre à ton serveur local. Je ne vois pas bien où on gagne en simplicité.
- Le fait d'avoir un proxy local toujours "up" avec plein de clients revient à refaire en local l'architecture de jabber : Le serveur Jabber sait déjà gérer les événements quand tu n'es pas connecté et te les renvoyer plus tard, pas besoin d'avoir un proxy local "toujours connecté" qui redispatche. De même ton serveur sait déjà gérer des clients multiples, pas besoin d'un proxy local là non plus.
Le seul gain est celui que tu donnes, pouvoir cliquer sur le roaster d'une appli pour que ce soit une autre qui ouvre la fenetre de discussion. En pratique j'ai du mal à voir l'intérêt que ça aurait mais peu importe : ça va nécessiter de développer un mini protocole pour savoir passer un truc d'une appli à l'autre, ou dire à laquelle on destine quoi. Au final ça aurait pu être fait en n'implémentant que la couche dbus sur tes applications, que l'application qui gère le roaster sache envoyer un message "ouvre une conversation sur X" à celle qui gère les discussions. Chacun peut garder sa connexion directe au serveur jabber, tu n'as pas besoin d'avoir un proxy local jabber pour ça.
Non parce que à force tu vas te rendre compte que ça serait même méga génial que ton petit proxy dbus puisse aussi converser avec une appli distante sur ton NAS par exemple. Là tu vas ouvrir ton proxy "local" au réseau. Au final tu auras juste recréé un nouveau serveur jabber, ou plutot un proxy.