Face à la pression des développeurs, Google a décidé de faire marche arrière en ne supprimant pas l'accès CalDav de ces produits.
Par la même occasion, ils en ont profité pour ouvrir un accès CardDav
http://googledevelopers.blogspot.nl/2013/06/making-googles-caldav-and-carddav-apis.html
# Pas au courant
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 saltimbanque (site web personnel) . Évalué à 2.
en plus y sont pas gentils ils ne publient pas d'API google keep
[^] # Re: Pas au courant
Posté par jeekajoo (site web personnel) . É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 CrEv (site web personnel) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Ils plient sous les protestations. Leur volonté d'origine était claire : fermeture, fermeture, fermeture.
[^] # Re: Pas au courant
Posté par CrEv (site web personnel) . Évalué à 8.
Sauf que :
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 flagos . Évalué à 7.
XMPP ?
[^] # Re: Pas au courant
Posté par CrEv (site web personnel) . Évalué à 1.
Sauf que là je parlais spécifiquement de l'épisode CalDav
[^] # Re: Pas au courant
Posté par hercule_savinien . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Oh, tous les logiciels de calendrier prenant en charge Google Calendar, une paille !
[^] # Re: Pas au courant
Posté par CrEv (site web personnel) . É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 flagos . Évalué à 10.
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 groumly . Évalué à 5.
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 ribwund . Évalué à 2.
Ça me surprendrait quand même que reader ait des centaines de millions d'utilisateurs…
[^] # Re: Pas au courant
Posté par groumly . Évalué à 0.
Et si on compte les utilisateurs actifs et qu'on enleve ceux a qui google a cree un compte sans rien leur demander et qui n'est strictement jamais utilise?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas au courant
Posté par ribwund . Évalué à 2. Dernière modification le 08 juin 2013 à 12:35.
Je parle pas d'utilisateurs avec compte google+ (> 500M y'a 6 mois), je parle de "monthly active users" sur plus.google.com (> 100M y'a 6 mois).
Edit: et les chiffres de Mai: http://techcrunch.com/2013/05/15/google-redesigns-its-stream-to-include-multi-column-google-now-esque-cards-auto-hashtags-and-more/ (390M actifs sur le web, 190M actifs sur le stream).
[^] # Re: Pas au courant
Posté par zebra3 . Évalué à 2.
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 CrEv (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6. Dernière modification le 06 juin 2013 à 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 Larry Cow . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Pourquoi ? Quel problème à proposer du SFTP à la place ?
[^] # Re: Pas au courant
Posté par Larry Cow . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
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 Larry Cow . Évalué à 2.
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 claudex . Évalué à 3.
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 zebra3 . Évalué à 2. Dernière modification le 07 juin 2013 à 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 claudex . É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 🚲 Tanguy Ortolo (site web personnel) . É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 claudex . É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 CrEv (site web personnel) . É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 Zenitram (site web personnel) . Évalué à 3.
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 ribwund . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à -1.
Ca n'a rien à voir avec une vision : utilise-le, et ça restera.
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 baron . Évalué à 2.
La main invisible de l'informatique en somme.
[^] # Re: Pas au courant
Posté par Zenitram (site web personnel) . É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 baron . Évalué à 0.
C'est amusant comme avec une phrase relativement neutre, on peut se faire incendier.
[^] # Re: Pas au courant
Posté par Zenitram (site web personnel) . É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 François (site web personnel) . É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 baron . É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 Firwen (site web personnel) . Évalué à 2.
http://en.wikipedia.org/wiki/Cloud_Data_Management_Interface
De rien
[^] # Re: Pas au courant
Posté par Firwen (site web personnel) . Évalué à 4. Dernière modification le 06 juin 2013 à 22:02.
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 CrEv (site web personnel) . Évalué à 1.
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.
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 zebra3 . Évalué à -3.
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 LeMagicien Garcimore . É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 zebra3 . Évalué à 1.
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 CrEv (site web personnel) . É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 LeMagicien Garcimore . É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 Maclag . É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 devnewton 🍺 (site web personnel) . Évalué à -6.
Du coup la voix/vidéo marche mal et personne ne connait XMPP. Merci Google!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas au courant
Posté par karteum59 . É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 Maclag . É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 claudex . Évalué à 5.
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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas au courant
Posté par Larry Cow . É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 devnewton 🍺 (site web personnel) . É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…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas au courant
Posté par Maclag . É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 karteum59 . Évalué à 1. Dernière modification le 08 juin 2013 à 12:08.
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 ribwund . Évalué à 3.
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 karteum59 . Évalué à 2. Dernière modification le 08 juin 2013 à 12:12.
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 antistress (site web personnel) . Évalué à 4.
Et ben s'ils l'ont pas fait, tu as ta réponse, non ?
[^] # Re: Pas au courant
Posté par claudex . Évalué à 4.
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 CrEv (site web personnel) . Évalué à 4.
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 gnumdk (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.