• # Pas au courant

    Posté par (page perso) . Évalué à 8.

    Intéressant, je n'étais pas au courant. Décidément, entre l'abandon partiel d'XMPP et la volonté loupée d'abandonner CalDAV, don't be evil aura vécu…

    • [^] # Re: Pas au courant

      Posté par (page perso) . Évalué à 2.

      en plus y sont pas gentils ils ne publient pas d'API google keep

    • [^] # Re: Pas au courant

      Posté par (page perso) . Évalué à 4.

      oui s'ils pouvaient faire machine arrière sur l'abandon de la fédération xmpp ça serait pas mal aussi

    • [^] # Re: Pas au courant

      Posté par (page perso) . Évalué à 2.

      don't be evil aura vécu…

      Justement non puisqu'ils font marche arrière et en rajoutent même.

      (après, j'ai de toute façon l'impression que pour certains du moment qu'il y a une entreprise c'est forcément mauvais…)

      • [^] # Re: Pas au courant

        Posté par (page perso) . Évalué à 5.

        Ils plient sous les protestations. Leur volonté d'origine était claire : fermeture, fermeture, fermeture.

        • [^] # Re: Pas au courant

          Posté par (page perso) . Évalué à 8.

          Sauf que :

          • y'a pas grand monde qui s'en servait pour de vrai (et maintenir ouvertes des choses dans le vent c'est pas forcément une bonne idée)
          • ils ont écouté les protestations des devs (ce qui est loin d'être une marque de fermeture)
          • ils en profitent pour en ouvrir d'avantage

          Donc la situation au final est comment ? Elle est pire qu'avant l'annonce initiale de fermeture ? Des choses ont été fermées ? Ou alors en réalité il y a encore plus d'API ouvertes aujourd'hui ?

          • [^] # Re: Pas au courant

            Posté par . Évalué à 7.

            Des choses ont été fermées ?

            XMPP ?

            • [^] # Re: Pas au courant

              Posté par (page perso) . Évalué à 1.

              Sauf que là je parlais spécifiquement de l'épisode CalDav

              • [^] # Re: Pas au courant

                Posté par . Évalué à -2.

                Pour en conclure que Google n'est pas evil.

                Donc tant que Google ne touche pas à CalDav, ils peuvent faire tout ce qu'ils veulent, ils ne sont pas evil.

                Le FN est un parti d'extrême droite

          • [^] # Re: Pas au courant

            Posté par (page perso) . Évalué à 6.

            y'a pas grand monde qui s'en servait pour de vrai (et maintenir ouvertes des choses dans le vent c'est pas forcément une bonne idée)

            Oh, tous les logiciels de calendrier prenant en charge Google Calendar, une paille !

            • [^] # Re: Pas au courant

              Posté par (page perso) . Évalué à 0.

              Ben faut croire en réalité. Ok ils ne fournissent pas les chiffres, mais ce qui a motivé leur décision c'est l'usage réellement fait de l'API.
              Et attention, l'API ne disparaissaient pas, elle était par contre accessible différemment (partenaires)

              Mais pour le coup je vois que tu éludes la question principale : au final, c'est mieux qu'avant ou pire comme situation ? (sans parler d'XMPP qui est un autre sujet)

              Leur annonce aura justement permis de mettre en évidence les usages "autres" et probablement moins visibles de leur côté.

              • [^] # Re: Pas au courant

                Posté par . Évalué à 10.

                Et attention, l'API ne disparaissaient pas, elle était par contre accessible différemment (partenaires)

                Justement. Donc le problème n'était pas de maintenir l'API comme tu nous le suggère puisque de toutes manières il était prévu que ce soit maintenu pour les partenaires.

                Donc non, la réalité, c'est qu'ils ne souhaitaient pas voir n'importe quelle appli se connecter sur leur serveur. De la fermeture quoi.

              • [^] # Re: Pas au courant

                Posté par . Évalué à 5.

                Ben faut croire en réalité. Ok ils ne fournissent pas les chiffres, mais ce qui a motivé leur décision c'est l'usage réellement fait de l'API.

                Des faux culs oui. Ils ont sorti la meme excuse bidon pour reader, alors qu'il est aussi utilise que g+, en rajoutant "faut qu'on se concentre", tout ca en annoncant des services a la con qq semaines plus tard.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: Pas au courant

            Posté par . Évalué à 2.

            et maintenir ouvertes des choses dans le vent c'est pas forcément une bonne idée

            En quoi ?

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Pas au courant

              Posté par (page perso) . Évalué à 0.

              Parce qu'il faut les maintenir par exemple. (ZenitramMode=on) Et ça prend du temps et le temps c'est de l'argent (ZenitramMode=off).
              Garder ouvert ça veut aussi dire qu'il va falloir faire évoluer (par ex si le backend change il faudra que l'API tourne toujours).
              Garder quelque chose d'ouvert alors que personne ne l'utilise (d'après eux) c'est se compliquer la vie je trouve. Il y a tellement d'API, de produits, que je trouve normal de garder un oeil dessus et régulièrement fermer celles qui deviennent peu utilisées / obsolètes / inutiles / …

              • [^] # Re: Pas au courant

                Posté par (page perso) . Évalué à 6. Dernière modification le 06/06/13 à 18:00.

                Avec une vision pareille, dans dix ou vingt ans on n'aura plus aucun protocole standard, des API spécifiques de partout, des logiciels spécifiques pour chaque service, aucune fédération entre services… J'en frissonne d'avance.

                Notez que ça a déjà commencé : à une époque on avait FTP, puis SFTP comme protocole standard et indépendant du service pour les transferts de fichiers, aujourd'hui la mode est aux clouds à API spécifique.

                • [^] # Re: Pas au courant

                  Posté par . Évalué à 2.

                  Notez que ça a déjà commencé : à une époque on avait FTP, puis SFTP comme protocole standard et indépendant du service pour les transferts de fichiers, aujourd'hui la mode est aux clouds à API spécifique.

                  Moué, des services payants "grand-public" s'appuyant sur une connectivité SFTP, je n'en ai pas croisé des masses. Le FTP a commencé à mourir avec la montée du Web (du moins dès que ce dernier a été capable de monter des fichiers). Le SFTP a toujours été un truc de spécialiste - fort pratique au demeurant.

                  Je ne peux pas dire que je sois fan de la mode actuelle des clouds à API spécifique, mais ça n'a rien à voir avec les protocoles standards. Ils n'auraient pas de protocole spécifique qu'ils feraient du "something-over-HTTP" (ce que beaucoup font en réalité).

                  • [^] # Re: Pas au courant

                    Posté par (page perso) . Évalué à 3.

                    ls n'auraient pas de protocole spécifique qu'ils feraient du "something-over-HTTP" (ce que beaucoup font en réalité).

                    Pourquoi ? Quel problème à proposer du SFTP à la place ?

                    • [^] # Re: Pas au courant

                      Posté par . Évalué à 2.

                      Pourquoi ? Quel problème à proposer du SFTP à la place ?

                      J'en sais rien : je ne connais pas le contenu de leurs APIs, ni les éventuels problèmes qui ont pu les pousser à les créer. Mais quand bien même ce serait un nouvel avatar du NIH, ça ne changerait pas grand chose : SFTP n'a pas été implémenté par beaucoup d'autres choses que clients SSH comme un bonus ("en plus du shell, vous pouvez transférer des fichiers!"). Les exceptions notables sont Cyberduck et Filezilla, pour autant que je sache. C'est peu pour un standard.

                      • [^] # Re: Pas au courant

                        Posté par (page perso) . Évalué à 3.

                        SFTP n'a pas été implémenté par beaucoup d'autres choses que clients SSH comme un bonus ("en plus du shell, vous pouvez transférer des fichiers!"). Les exceptions notables sont Cyberduck et Filezilla, pour autant que je sache. C'est peu pour un standard.

                        Aucune importance, une API spécifique n'a par définition été mise en œuvre par personne avant d'être créée ex nihilo.

                        • [^] # Re: Pas au courant

                          Posté par . Évalué à 2.

                          Aucune importance, une API spécifique n'a par définition été mise en œuvre par personne avant d'être créée ex nihilo.

                          Sauf que tu la maîtrises. Alors que prendre une API qui n'est pas la tienne et qui n'est pas/peu utilisée, c'est un peu suicidaire.

                    • [^] # Re: Pas au courant

                      Posté par (page perso) . Évalué à 3.

                      Pourquoi ? Quel problème à proposer du SFTP à la place ?

                      Se priver de beaucoup de clients qui sont derrière un pare-feu qui ne laisse passer que les port 80 et 443.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: Pas au courant

                        Posté par . Évalué à 2. Dernière modification le 07/06/13 à 09:09.

                        Ben y'a SSLH pour ça.

                        Je sais, c'est un contournement, mais ça ça marche.

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                        • [^] # Re: Pas au courant

                          Posté par (page perso) . Évalué à 3.

                          Et du coup, ça complique l'utilisation et les clients préféreront aller chez le concurrent qui est plus simple à utiliser (c'est un des points forts d'Amazon par exemple).

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                          • [^] # Re: Pas au courant

                            Posté par (page perso) . Évalué à -1.

                            N'importe quoi. En utilisant une API spécifique, il faut coder un client. En utilisant un protocole existant mais en le détournant un peu, ici en changeant son port d'utilisation, il faut au pire coder aussi un client en réutilisant des bibliothèques existantes, au mieux adapter un client existant. Bref, moins de travail.

                            • [^] # Re: Pas au courant

                              Posté par (page perso) . Évalué à 3.

                              Si tu as besoin d'un client spécifique pour faire du transfert de fichiers en HTTP ou accéder à une URL en HTTP, je me demande comment tu poste sur Linuxfr. Sans compter que chez Google, ils doivent quand même développer le client vu qu'ils font du web.

                              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: Pas au courant

                              Posté par (page perso) . Évalué à 2.

                              Et dans pas mal de cas le fournisseur de l'API va te fournir aussi des libs compatibles.
                              Comme ça tu fais ton client à partir de lib existantes. Et ça devient le même cas.

                            • [^] # Re: Pas au courant

                              Posté par (page perso) . Évalué à 3.

                              En utilisant une API spécifique, il faut coder un client.

                              Tu es au courant que l'API S3 est du bête HTTP un peu étendu?
                              Tu penses sérieusement que SFTP sur du HTTP est plus simple à gérer que du bête HTTP avec quelques codes en plus?

                              Le problème est peut-être la complexité du bordel "standard" (sic, SFTP n'est pas standard du tout) face à la simplicité des API du cloud que tout le monde implémente très rapidement sans se poser de question métaphysique.

                              C'est peut-être pour ça que ça marche.

                    • [^] # Re: Pas au courant

                      Posté par . Évalué à 2.

                      Quel problème à proposer du SFTP à la place ?

                      Parce que y'a pas l'infra pour (même question que: pourquoi google ne propose pas git via git://).

                • [^] # Re: Pas au courant

                  Posté par (page perso) . Évalué à -1.

                  Avec une vision pareille, dans dix ou vingt ans on n'aura plus aucun protocole standard,

                  Ca n'a rien à voir avec une vision : utilise-le, et ça restera.

                  aujourd'hui la mode est aux clouds à API spécifique.

                  Peut-être parce que les standard sont limités, et que les "concurrents" libristes ne sont pas foutu de proposer un standard utilisable?

                  Bon, ben maintenant, je t'en prie, propose… En attendant, le monde bouge (plus vite qu'à l'époque de la standardisation de FTP). Si il y a un besoin, ça ira très bien (dans d'autres domaines, ça standardise, cf H265 pendant que les libristes laissent une entreprise privée définir un "standard" concurrent fait par 1 entreprise et 1 seule, l'hôpital qui se fout de la Charité)

                  • [^] # Re: Pas au courant

                    Posté par . Évalué à 2.

                    La main invisible de l'informatique en somme.

                    • [^] # Re: Pas au courant

                      Posté par (page perso) . Évalué à 3.

                      Ah la belle incohérence libriste :
                      - Il y a 36 protocoles librement utilisables pour s'interfacer avec le desktop Linux, "c'est la liberté, c'est génial"
                      - Il y a 36 protocoles librement utilisables pour faire des paquets Linux, "c'est la liberté, c'est génial"
                      - Il y a 36 (en pratique, beaucoup moins dans les connus) protocoles librement (oui, certains s'amuser à être "compatible Amazon S3") utilisables pour le cloud "c'est la liberté, c'est horrible"

                      Commencez donc à balayer devant vôtre porte, faites des standards entre libristes convaincus, pour montrer que c'est utile. En attendant, les logiciels ont juste ajouté un protocole en plus genre "Amazon S3" (l'API est toute bête, aucun brevet dessus) et ça marche du tonnerre. C'est exactement la liberté prônée par le libre, mais quand ça plait pas, on va cracher dessus en accusant de ce qu'on aime d'habitude, va comprendre…

                      • [^] # Re: Pas au courant

                        Posté par . Évalué à 0.

                        C'est amusant comme avec une phrase relativement neutre, on peut se faire incendier.

                        • [^] # Re: Pas au courant

                          Posté par (page perso) . Évalué à 0.

                          "La main invisible" est souvent utilisée en tant que critique sous entendu du "grand méchant capital qui ne marche pas c'est horrible" ou "tout serait plus simple dans un monde bisounours où les autres font ce que je demande" avec un bonus "J'en frissonne d'avance".
                          Si ce n'est pas le cas, je m'excuse de ma réaction.
                          Si c'est le cas, je maintien mes propos.

                          • [^] # Re: Pas au courant

                            Posté par (page perso) . Évalué à 3.

                            La "main invisible" est une expression d'Adam Smith au dépard il me semble et elle est utilisée par la plupart des néolibéraux, notamment pour avoir une argumentation positive à leur vision de ce qu'est une bonne économie politique.

                            • [^] # Re: Pas au courant

                              Posté par . Évalué à 0.

                              C'est d'ailleurs une expression malheureuse à mon sens. On peut en effet penser qu'un système économique est dirigé par certaines lois, mais je ne comprend pas l'utilisation de cette expression. La crédibilité des lois physiques ne se sont établies qu'au moment où l'on a retiré toute référence divine ou semi-divine.

                  • [^] # Re: Pas au courant

                    Posté par (page perso) . Évalué à 2.

                    Bon, ben maintenant, je t'en prie, propose… En attendant, le monde bouge

                    http://en.wikipedia.org/wiki/Cloud_Data_Management_Interface

                    De rien

                • [^] # Re: Pas au courant

                  Posté par (page perso) . Évalué à 4. Dernière modification le 06/06/13 à 22:02.

                  Notez que ça a déjà commencé : à une époque on avait FTP, puis SFTP comme protocole standard et indépendant du service pour les transferts de fichiers, aujourd'hui la mode est aux clouds à API spécifique.

                  SFTP, FTPS, pNFS, AFS, gsiFTP, SMB & so on sont POSIX-like donc supportent les random I/O ( particulièrement le random write ) et par conséquent ne sont pas adapté aux cloud storages qui sont généralement conçus pour du write-once / read many pour des raisons de scalabilités ( cf NRW, R >> W ).

                  Le principal interet de HTTP, outre le coté Web et le passage outre des problèmes de pare-feu, est le coté atomic de l'operation "PUT" qui match parfaitement le "write-once".

                  Mais je t'accorde que ça ne justifie absoluement pas la diversité en terme d'API : S3, Swift, Azure, WebDav, Google Drive, Rackspace, etc…

                • [^] # Re: Pas au courant

                  Posté par (page perso) . Évalué à 1.

                  Avec une vision pareille, dans dix ou vingt ans on n'aura plus aucun protocole standard, des API spécifiques de partout, des logiciels spécifiques pour chaque service, aucune fédération entre services…

                  Et ben vas-y, supporte-les les standards, développe-les. Propose tes services aux nombreuses boites qui en auraient bien besoin.
                  Mais ne reporte pas la faute sur les autres.
                  Si FTP a coulé c'est parce que c'est juste chiant à utiliser. SFTP ? Mouai, jamais vraiment vu utilisé.
                  Mais personne ne t'oblige à utiliser les services de Google.

                  aujourd'hui la mode est aux…

                  Oué enfin c'est aussi que ça correspond à ce qu'une bonne partie des utilisateurs (et même des développeurs) veulent.

              • [^] # Re: Pas au courant

                Posté par . Évalué à -3.

                Parce qu'il faut les maintenir par exemple.

                Maintenir quoi ? DAV, c'est un standard, ça évolue quand même pas des masses

                Tu mets un Apache et basta, la maintenance, c'est un coup d'apt-get.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Pas au courant

                  Posté par . Évalué à 5.

                  Ah bon ? et magiquement ça va s'interfacer avec le reste de leur produits (Drive, Calendar, et je sais pas quoi d'autre,…) ? C'est génial l'informatique comme même !

                  • [^] # Re: Pas au courant

                    Posté par . Évalué à 1.

                    et magiquement ça va s'interfacer avec le reste de leur produits (Drive, Calendar, et je sais pas quoi d'autre,…)

                    Pas magiquement, mais c'est pas non plus un boulot monstrueux. Les gars d'ownCloud y arrivent bien.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Pas au courant

                      Posté par (page perso) . Évalué à 2.

                      Je ne suis pas certains que ce soit la même charge de boulot (aussi bien puisse être owncloud, je pense qu'il y a encore du taff). Ni les mêmes contraintes (par ex de scalabilité).

                    • [^] # Re: Pas au courant

                      Posté par . Évalué à 2.

                      Bien au contraire!
                      On parle pas juste du dev, il y aussi les tests, QA, la prod,… Ca implique un peu plus de ressources qu'une centaine de lignes de php et un tgz

    • [^] # Re: Pas au courant

      Posté par . Évalué à 10.

      Je ne veux pas relancer le troll ici, mais… euh si, je vais quand même le faire:

      Est-ce que Google abandonne la voie XMPP parce qu'ils sont devenus méchants, ou parce qu'ils sont arrivés à la conclusion que XMPP était devenu un handicap pour eux?

      Je regarde ce que fait leur nouveau bousin et quand je me dis le temps qu'il a fallu pour que Jingle devienne une spec, je me dis aussi que s'ils avaient voulu ne serait-ce que proposer un standard à fonctionnalités égales, on aurait attendu encore 5ans ou plus avec en bonus des remarques acérées sur le fait que "l'implémentation de Google n'est pas celle du standard!" (ben oui: soit le standard a changé depuis la proposition par Google, soit Google a changé sa manière de faire ces dernières années, etc.)

      Bref, je ne pense pas que Google ait juste décidé de devenir "evil". Aucune entreprise ne décide de trucs comme ça. Mais ils ont choisi une solution technique qui les emmène dans une direction claire, et cette direction implique la fin de XMPP chez Google.

      Le côté "evil", on le verra s'ils libèrent les specs du protocole voire le code des serveurs et clients, pas dans un choix technique de ne pas soutenir une techno qui les a déçus.

      Avant qu'ils ne l'utilisent, XMPP était très marginal. En quoi est-ce qu'ils devraient quoi que ce soit à "XMPP"? C'est plutôt le contraire!
      Google a contribué à XMPP techniquement (voix-vidéo) et par son aura. Si XMPP n'est toujours pas LE réseau qui les fédère tous après ça, c'est quand même pas la faute de Google!!

      • [^] # Re: Pas au courant

        Posté par (page perso) . Évalué à -6.

        Google a contribué à XMPP techniquement (voix-vidéo) et par son aura

        Du coup la voix/vidéo marche mal et personne ne connait XMPP. Merci Google!

        http://devnewton.bci.im

      • [^] # Re: Pas au courant

        Posté par . Évalué à 2.

        Le problème venait-il de XMPP en tant que protocole fondamentalement inadapté, ou de la myriade de clients XMPP qui implémentaient la moitié des fonctionnalités et la manière intrinsèquement lente de définir un standard ?
        Dit autrement : qu'est-ce qui empêche Google de développer son Hangouts sur la base de XMPP + des extensions/XEP à eux ? (qu'ils rendraient publiques mais qu'ils définiraient seuls à la vitesse et de la manière qui leur convient).

        (cela dit, j'avoue que pour la voix/vidéo, un protocole de signalisation du type IAX2 qui n'utilise qu'un seul port multiplexé pour la sig + les données me semble plus simple pour traverser les NATs, donc peut-être que effectivement XMPP était fondamentalement inadapté…)

        • [^] # Re: Pas au courant

          Posté par . Évalué à 3.

          De ce qu'ils disent, ça semble être une décision technique: XMPP n'était pas le meilleur candidat pour Hangout, et le reste des avantages de XMPP (la fédération) ne semble jamais avoir profité à Google).

          Avant de leur gueuler dessus parce qu'ils s'éloignent de XMPP dans leur nouvelle suite de communication entre individus, est-ce que quelqu'un est capable de donner concrètement des arguments en faveur du maintien de XMPP du point de vue de Google? Qu'est-ce qu'ils y gagnent?
          Si la réponse c'est juste "la reconnaissance des geeks et donc de développeurs bénévoles", c'est à la limite de la prise d'otage.

          Si Google finance une association caritative pendant des années, on va leur tomber dessus le jour où ils arrêtent?

          Cela dit, on peut aussi avancer l'hypothèse que l'option système fermé à code source fermé faisait partie du cahier des charges, et donc XMPP n'était plus une option valide.

          Dans tous les cas, je continuerai à penser que Google ne doit rien à la "communauté XMPP".

          • [^] # Re: Pas au courant

            Posté par (page perso) . Évalué à 5.

            Si Google finance une association caritative pendant des années, on va leur tomber dessus le jour où ils arrêtent?

            Tu risque d'être surpris des réaction le jour où ils annonceront qu'ils arrête le Summer of Code.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Pas au courant

            Posté par (page perso) . Évalué à 2.

            Tu as tout à fait raison, le "marché" n'est pas un bon système pour garantir interopérabilité.

            Il faudrait une loi imposant l’interopérabilité des messageries avec de bonnes grosses amendes pour les mauvais joueurs.

            http://devnewton.bci.im

            • [^] # Re: Pas au courant

              Posté par . Évalué à 3.

              Et tu t'appuie sur quoi pour édicter cette loi? C'est quoi l'organisme qui interdit (contre amendes) l'utilisation de certains protocoles? Et une fois qu'elle existe, comment tu peux garantir qu'elle ne se mettra pas un jour à filtrer des protocoles qui t'arrangeaient?

              • [^] # Re: Pas au courant

                Posté par (page perso) . Évalué à 2.

                Il faudrait simplement s'inspirer de ce qui se fait ailleurs: il y a bien plusieurs opérateurs téléphoniques et pourtant tout le monde peut s'appeler…

                http://devnewton.bci.im

                • [^] # Re: Pas au courant

                  Posté par . Évalué à 0.

                  "simplement"?

                  Dans le cas de la téléphonie mobile, comme du wifi, il y a un levier pour les autorités: l'autorisation d'utiliser ou pas certaines fréquences, et dans quelles conditions.

                  L'État peut donc imposer un standard de communication en échange de l'octroi de la licence.

                  De plus, le marché est complètement différent: personne n'aurait l'idée ni les moyens d'acheter un téléphone par opérateur, c'est bien trop coûteux.

                  Là on parle de protocole qui n'ont pas besoin d'autre chose que des logiciels, c'est du pur soft, et si Facebook utilise XMPP, ça ne perturbe pas les communications intra réseau Google.
                  Tout le monde peut créer un compte "gratuitement" chez l'un et l'autre en même temps.

                  Si tu t'amuses à faire des lois sur les protocoles haut-niveau logiciels, t'as pas fini:
                  Un exemple d'attaque:
                  -deux logiciels qui communiquent sur le réseau, ça rentre ou pas dans le protocole?
                  -si en plus je peux leur envoyer des commandes à distance?
                  -et si ces commandes à distances finissent par notifier un humain?
                  -en quoi un logiciel de messagerie est différent? c'est juste que tu ne vois pas la commande que tu envoies?
                  Alors tout logiciel qui communique sur le réseau doit utiliser ton protocole. Ça va être la misère pour la transparence réseau des applis…

                  Un autre? Inspirons-nous donc de la téléphonie mobile:
                  Désormais, tout acteur qui veut lancer un logiciel de messagerie devra… faire certifier son logiciel par les autorités. Ça va être folklo ça pour le Libre…

                  • [^] # Re: Pas au courant

                    Posté par . Évalué à 1. Dernière modification le 08/06/13 à 12:08.

                    Dans le cas de la téléphonie mobile, comme du wifi, il y a un levier pour les autorités: l'autorisation d'utiliser ou pas certaines fréquences, et dans quelles conditions. L'État peut donc imposer un standard de communication en échange de l'octroi de la licence.

                    En fait non, le levier est ailleurs désormais. Depuis la mise en place de l'approche WAPECS en Europe, tout nouveau spectre se doit de garantir la neutralité technologique, modulo quelques contraintes génériques telles que les block edge masks (voir le rapport CEPT 19 à ce sujet). C'est notamment le cas des bandes 3.5 GHz, 2.5 GHz et 800 MHz (e.g. personne n'est obligé de déployer du LTE dans les bandes "4G"—à ceci près qu'aucune autre technologie ne répond aujourd'hui aux contraintes définies en terme de débit, mode de duplexage FDD dans les bandes de fréquences définies, etc.). La CEPT travaille d'ailleurs aujourd'hui sur la neutralité technologiques pour les bandes 900 et 1800 MHz (afin qu'on puisse notamment y déployer du LTE/WiMAX).

                    La raison pour laquelle le LTE "gagne" (et pour laquelle toutes les technologies concurrentes comme le WiMAX sont mortes) est ailleurs, dans les économies d'échelles au niveau industriel: personne ne va investir des millions en coûts fixes de R&D pour une technologie qui ne draine que des petits volumes. "The winner takes it all"…

                    Pour reprendre un autre exemple: personne n'est obligé non plus de se restreindre au wi-fi dans la bande ISM. Pourtant, les concurrents comme HomeRF et HiperLAN sont morts et enterrés depuis longtemps, pour des raisons de volumes et d'économies d'échelles.

        • [^] # Re: Pas au courant

          Posté par . Évalué à 3.

          Le problème venait-il de XMPP en tant que protocole fondamentalement inadapté, ou de la myriade de clients XMPP qui implémentaient la moitié des fonctionnalités et la manière intrinsèquement lente de définir un standard ?

          C'est un peu le problème de xmpp qui est trop extensible (du coup personne ne supporte le même sous ensemble de fonctionnalités).

          • [^] # Re: Pas au courant

            Posté par . Évalué à 2. Dernière modification le 08/06/13 à 12:12.

            C'est un peu le problème de xmpp qui est trop extensible (du coup personne ne supporte le même sous ensemble de fonctionnalités).

            Le fait que le protocole soit "trop souple" est un souci pour l'interopérabilité sur les fonctionnalités avancées, mais pas un souci en soi pour que Google fasse un produit fini ("aussi bien que Skype") qui marche bien avec lui-même. C'est donc que le problème est ailleurs: soit XMPP n'est pas adapté en soi (par exemple: XML trop verbeux, NAT compliqué car ports différents entre signalisation et données, etc.), soit avoir un protocole fermé faisait partie du cahier des charges comme l'évoquait Maclag.

      • [^] # Re: Pas au courant

        Posté par (page perso) . Évalué à 4.

        Le côté "evil", on le verra s'ils libèrent les specs du protocole

        Et ben s'ils l'ont pas fait, tu as ta réponse, non ?

      • [^] # Re: Pas au courant

        Posté par (page perso) . Évalué à 4.

        Mais ils ont choisi une solution technique qui les emmène dans une direction claire, et cette direction implique la fin de XMPP chez Google.

        Sauf que ça marche toujours.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Pas au courant

          Posté par (page perso) . Évalué à 4.

          cette direction implique la fin de XMPP chez Google.

          Sauf que ça marche toujours.

          Et surtout que ça risque fort de continuer puisqu'ils utilisent XMPP pour Cloud Print, Sync ou Play Games Services (voir commentaire de pterjan qui si je ne me trompe bosse chez Google)

          • [^] # Re: Pas au courant

            Posté par (page perso) . Évalué à 2.

            En fait, Google Hangout propose pour les clients lourds une couche de compatibilité XMPP. Et je trouve cela logique de la part de Google d'avoir rajouté cette couche, histoire d'avoir des clients compatibles dès la sortie du produit. Reste à savoir si elle restera mais je ne vois pas de raison vu que aujourd'hui, les 3 gros acteurs utilisent ce protocole: Facebook, Microsoft Live et G+

            Par contre, effectivement, il est dommage que la politique futur vis à vis de l'accès vers des comptes extérieurs ne soit pas plus claire: en gros, est ce que hangout sera capable de discuter un jour avec des comptes jabber.

Suivre le flux des commentaires

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