Alors quand tu dit "hangout" sans 's', ça désigne l'interface de vidéo conférence dans Google+, celle qui permet de se voir à plusieurs.
Par contre, Hangouts est le système tout en un qui (à terme) va unifier les systèmes de communication proposé par Google ( ie, hangout, talk, google voice, les sms, et les mails ). L'idée à terme, de ce que j'ai compris et ce que je me souviens, c'est bien d'avoir 1 logiciel qui gère tout. Je ne sais pas si c'est le cas sur android avec gtalk, j'ai pas de compte Google donc mon téléphone professionnel a 2 interfaces pour les sms et la messagerie xmpp, mais sur mon téléphone perso, ç'est une seule interface commune.
Ensuite, le logiciel pour gérer ça n'était visiblement pas encore fini. Tu va me dire "c'est un soft web, c'est jamais fini" et je dirait oui, ça bouge tout le temps. Mais la, l'intégration de la fédération n'est pas encore la, tout comme l'intégration voix/sms.
Donc le fait de ne pas avoir de fédération xmpp dans hangouts n'est pas lié au fait que Google avait temporairement suspendu les invitations venant de la fédération.
Et le souci, c'est pas le revirement de Google pour xmpp. C'est qu'il n'y a pas de raison de pas faire de xmpp en sortie vers la fédération pour envoyer des messages. Si l'argument est "Google ne peux offrir une expérience riche qu'en forçant les gens à avoir un compte Google et une application spécifique", va falloir m'expliquer comment ils vont faire pour les SMS (http://www.digitaltrends.com/mobile/google-hangouts-sms-soon/), sachant que tout le monde n'a pas un compte Google et un téléphone Android avec hangouts. Donc le cas "j'ai des gens en dehors de compte google parmi mes contacts" est déjà un cas existant qu'ils doivent prendre en compte. Tout comme le fait de faire des appels voix en dehors des gens ayant un compte Google via Google Voice.
Et le code de gestion du xmpp dans un backend est aussi un code qu'ils doivent garder, car ç'est utilisé pour divers services internes, donc l'argument de "ça permet de libérer des ressources" n'est pas vraiment recevable.
# Subtile différence sémantique
Posté par Misc (site web personnel) . En réponse au journal Google+ Hangouts et Jabber/XMPP. Évalué à 3.
Alors quand tu dit "hangout" sans 's', ça désigne l'interface de vidéo conférence dans Google+, celle qui permet de se voir à plusieurs.
Par contre, Hangouts est le système tout en un qui (à terme) va unifier les systèmes de communication proposé par Google ( ie, hangout, talk, google voice, les sms, et les mails ). L'idée à terme, de ce que j'ai compris et ce que je me souviens, c'est bien d'avoir 1 logiciel qui gère tout. Je ne sais pas si c'est le cas sur android avec gtalk, j'ai pas de compte Google donc mon téléphone professionnel a 2 interfaces pour les sms et la messagerie xmpp, mais sur mon téléphone perso, ç'est une seule interface commune.
Ensuite, le logiciel pour gérer ça n'était visiblement pas encore fini. Tu va me dire "c'est un soft web, c'est jamais fini" et je dirait oui, ça bouge tout le temps. Mais la, l'intégration de la fédération n'est pas encore la, tout comme l'intégration voix/sms.
Donc le fait de ne pas avoir de fédération xmpp dans hangouts n'est pas lié au fait que Google avait temporairement suspendu les invitations venant de la fédération.
Et le souci, c'est pas le revirement de Google pour xmpp. C'est qu'il n'y a pas de raison de pas faire de xmpp en sortie vers la fédération pour envoyer des messages. Si l'argument est "Google ne peux offrir une expérience riche qu'en forçant les gens à avoir un compte Google et une application spécifique", va falloir m'expliquer comment ils vont faire pour les SMS (http://www.digitaltrends.com/mobile/google-hangouts-sms-soon/), sachant que tout le monde n'a pas un compte Google et un téléphone Android avec hangouts. Donc le cas "j'ai des gens en dehors de compte google parmi mes contacts" est déjà un cas existant qu'ils doivent prendre en compte. Tout comme le fait de faire des appels voix en dehors des gens ayant un compte Google via Google Voice.
Et le code de gestion du xmpp dans un backend est aussi un code qu'ils doivent garder, car ç'est utilisé pour divers services internes, donc l'argument de "ça permet de libérer des ressources" n'est pas vraiment recevable.