Après avoir lu un peu tout et n'importe quoi à son sujet, de « Wave va tuer HTTP » à « Wave est le remplaçant de Twitter, de Facebook, du mail, etc etc ». Restons sérieux un instant en se concentrant sur ce qu'est Google Wave : un protocole, une plate-forme et un produit.
Un protocole étendant XMPP
Bon on commence par ce qui a fait sourire tous les geeks en lisant la spec :
The Google Wave Federation Protocol is an open extension to XMPP core [RFC3920] protocol to allow near real-time communication between two wave servers.
C'est Open-Source et vous pouvez installer votre serveur Wave chez vous. Par contre ça conserve une architecture provider/consumer et il n'y a pas de possibilités de faire du peer-to-peer - ou plutôt wave-to-wave - et le provider initial garde le contrôle sur la wave (je détaille un peu ces parties techniques car ça aura son importance sur la suite) :
The operational transform used for concurrency control in wave is [currently] based on mutation of a shared object owned by a central master. As a result, in order to achieve federation while still respecting the concurrency control protocol, only one server may 'own', or be 'authoritative' for a given wave (and its operations), regardless of whether the participants use different service providers.
Et oui il ne faut pas se laisser avoir par les community principles :
Wave is a distributed network model: traffic is routed peer-to-peer, not through a central server
Qui parlent bien de trafic, chaque mot a son importance dans le marketing. C'est un beau pied de nez à la folie du Cloud de la part de Google : qu'importe le support, la donnée restera à nous !
En conclusion sur le protocole, rien de bien extraordinaire, si ce n'est que l'on en arrive à une position de Embrace, extend and extinguish qui a fait le monopole de Microsoft pendant de trop longues années...
Une plate-forme pour robots
Ça c'est ce qu'on voit sur toutes les captures et videos Google, et effectivement ils ont compris avec Facebook que la construction d'une plate-forme suffisait pour conserver le contrôle sur les données. Pas besoin de s'embêter à faire trop d'applications (la suite Google suffira), des développeurs payés des cacahuètes vont s'en charger pour eux :-).
Pas grand chose à redire là-dessus, si ce n'est que Google va tout faire pour que vous initiez vos waves chez eux, forcément (cf plus haut). Au passage, vous allez sûrement apprendre GWT, ce qui renforcera la force développante Google.
Un produit Google
Et c'est là où ça devient intéressant. Toute la présentation est basée sur la plate-forme car parler d'un protocole est chiant à mourir et mettre en avant un produit Google peut faire peur. Mais c'est pourtant la finalité de Google Wave : transformer Chrome en un notificateur unique, un Wave browser qui lui procurerait un avantage difficilement rattrapable par la concurrence. Le produit sera bien sûr compatible avec les autres navigateurs mais optimisé pour Chrome (comme le sont les Google Apps). Je me demande d'ailleurs dans quelle mesure le produit pourra tourner sur App Engine.
Pour conclure, on a pu assister à la sortie d'un produit Google déguisé sous une plate-forme (pour faire plaisir aux commerciaux qui vont pouvoir vendre de la wave jusqu'à plus soif) et un protocole (ouvert, pour faire plaisir aux geeks), mais dans l'usage il y aura 95% de waves Google, soyons réalistes (et optimistes, sinon j'aurais mis 99%). Ça n'en reste pas moins un excellent produit basé sur un protocole qui a fait ses preuves, en rajoutant une couche de marketing à la Google, ça ne peut que marcher !
Là où je suis surpris c'est qu'ils aient choisi de garder un historique des waves alors qu'à l'ère du flux j'aurais plutôt eu tendance à privilégier l'instantanéité face au versionnement. Après il y a probablement un cap psychologique que l'on est pas encore prêts à franchir à ce niveau aussi (surtout pour les entreprises !). Mais ça viendra ;-).
Quoi qu'il en soit, le real-time tant attendu ne va pas nous aider à avoir des réflexions plus poussées, pas très réjouissant ça (dit-il en écrivant devant Roland Garros...).
Commentaires
Simon Rozet le 05/06/2009 :
La vidéo etant tellement "verbose", j'ai abandonné et me suis dis que l'info viendrai bien à moi, ce qui est chose faite grâce à toi; merci donc pour ce résumé, qui confirme ce que je pensais après 10 minutes de la vidéo: bullshit. :-)
Par contre, en parlant de chrome, quelque chose de (IMHO) plus intéressant: "purely evented I/O for v8 javascript" http://github.com/ry/node
MrThieu le 05/06/2009 :
Ce que j'ai encore du mal à comprendre dans le monde de l'informatique et partout ailleurs en fait, c'est que beaucoup, pour ne pas dire tous, exigent des applications utile, personnalisable et compatible entre elles. Mais personne ne veux dépendre d'un groupe unique, comme Microsoft, Apple ou Google.
Les sociétés développent des applications, il est logiques qu'elle en tirent profit, c'est la base de l'économie.
Les solution pour ne pas dépendre d'une société sont : soit de développer son propre produit. Et si le produit marche, on le distribue, le perfectionne, le vend, ... vous connaissez la suite. Soit on change de produit sans cesse (celle-ci semble la plus intéressante). Soit on n'utilise plus les produits, mais là, il y a bien moins d'intéresser.
Jeremy le 05/06/2009 :
Je ne comprend pas trop l'article. Tu es bien d'accord que si il y a une wave qui démarre entre des personnes de deux serveurs Wave qui ne sont pas chez Google. Google n'aura jamais les données ?
Forcement, vu que c'est Google qui lance le truc et que peut-être, beaucoup de gros acteurs ne suivront pas par principe. La majorité des serveurs seront des serveurs Google. Ça ressemble un peu à GMail avec des proportions plus grandes.
Au final j'ai l'impression que tu leur reproches d'être ce qu'ils sont, une grosse boite avec une grosse base d'utilisateur.
Au niveau de la vidéo, elle est destinée aux développeurs, et ce qui en jette surtout, c'est l'utilisation de http://en.wikipedia.org/wiki/Comet_(programming) très importante sur le client et la synchro xmpp entre les serveurs. Enfin, c'est ce qui m'a emballé!
David, biologeek le 05/06/2009 :
@Simon Rozet : non pas bullshit quand même :-)
D'un point de vue technologique c'est une bonne avancée et ils ont su tirer profit de XMPP sans réinventer la roue, ce qui est déjà pas mal.
Franchement, je suis persuadé que l'on peut faire des trucs géniaux avec les waves et que ça pourrait grandement contribuer à faciliter la communication qui passe aujourd'hui par un peu trop de canaux (ou alors je vieillis :p).
@MrThieu : les geeks sont d'éternels idéalistes que veux tu ;-)
> Les sociétés développent des applications, il est logiques qu'elle en tirent profit, c'est la base de l'économie.
De l'économie telle que nous la connaissons (et qui a montré ses limites). Mais je pense qu'il y a d'autres économies possibles, surtout pour le Web.
@Jeremy : je suis d'accord avec toi sur les waves non-googwelliennes.
> Au final j'ai l'impression que tu leur reproches d'être ce qu'ils sont, une grosse boite avec une grosse base d'utilisateur.
J'essaye surtout de montrer aux personnes qui me disent « Google c'est le bien et leurs produits gratuits sont super sexy » que cette gratuité apparente a un prix et que Google n'est pas un bienfaiteur de l'humanité.
Au-delà de ça, je suis admiratif devant certains choix stratégiques et Wave en est un.
Simon Rozet le 06/06/2009 :
@David: pour clarifier, par bullshit je voulais dire que IMHO, il y a des technologies très intéressantes, qui entrent dans une logique d'évolution plutot que de révolution, complètement ouvertes, sans le buzz, la machine marketing, etc. D'un autre côté, tout se que j'ai lu sur le sujet c'est ton article, celui de Joe Gregario (http://bitworking.org/news/431/wave-first-thoughts) et un rapide survole de la spec. La prochaine fois j'éviterai d'utiliser "bullshit" sans avoir vraiment de quoi nourrir le troll... ;-)
SnippyHolloW le 06/06/2009 :
Je suis plutôt d'accord sur le fait que ça peut être pas mal si ça unifie IRC / MSN / Gtalk / Mails et j'en passe. Surtout avec les améliorations possibles. Après, là où je doute : il faut absolument que l'on puisse monter un serveur "chez soi" et je pense que l'infrastructure serveur nécessaire à un serveur Wave n'est pas accessible à M. Geek (je ne parle pas de Mme Michu). Par exemple quand on voit de la correction orthographique "online", je pense (conjecture, fait l'hypothèse) que ça fonctionne comme leur système de traduction : statistiquement. Et qui dit comme ça, dit tables de correspondances de plusieurs Go (qui doivent tenir en mémoire pour des performances potables). La traduction c'est différent, ça se fait par un bot qui peut rester hébergé chez google.
Ça reste une bonne grosse évolution que je vais garder à l'oeil. Tout comme Google Corp., mais là ils me semblent faire "bien" les choses.
jeremy le 06/06/2009 :
Pour information, le correcteur syntaxique Spelly, et ce qui detecte les liens Linky sont aussi des bots. La difference c'est qu'ils sont ajouté automatiquement dans chaque wave.
Tu pourras surement decider de mettre des bots par defaut sur ton propre serveur. Par contre Spelly sera toujours chez google.
Sophie Gironi le 06/06/2009 :
Je viens mettre mon nez de fille (et pire, de marketeuse) dans votre discussion de geeks, j'espère que vous ne m'en voudrez pas.
J'ai lu cet article et ses commentaires avec beaucoup d'intêrêt. Mariée à un geek et bossant dans un univers plutôt technique, j'arrive à peu près à comprendre vos arguments... et je suis relativement d'accord avec vous.
Sauf que le web, aujourd'hui, est accessible à Mme Michu... et il y a beaucoup de Mme Michu. Prof de e-marketing en plus de mes fonction en agence interactive, je suis au contact d'élèves de différents niveaux et je suis étonnée (pour ne pas dire choquée) de voir que la génération dite "digital native" n'a aucune idée de ce qui constitue le web techniquement, et s'en fiche éperdument.
Ce qui compte, aujourd'hui, au yeux des 99% d'internautes non geeks (et je suis optimiste en pensant qu'il y a 1% de geek parmi nous) c'est l'usage. Et sincèrement, les usages que Wave laisse entrevoir du web de demain et bien... vous m'excuserez pour l'expression... c'est bandant :)
Damien B le 06/06/2009 :
"Là où je suis surpris c'est qu'ils aient choisi de garder un historique des waves alors qu'à l'ère du flux j'aurais plutôt eu tendance à privilégier l'instantanéité face au versionnement."
Une des premières applications de Wave est de remplacer Gmail ainsi que tous ces protocoles mal fagotés comme SMTP, IMAP et POP (IMAP étant tellement mal fagotés que les meilleurs ingénieurs de l'univers n'ont pas réussi à l'implémenter). Sans historique : pas de remplacement des mails.
David, biologeek le 12/06/2009 :
@Sophie Gironi:
> Je viens mettre mon nez de fille (et pire, de marketeuse) dans votre discussion de geeks
Han ! Le mal incarné ;)
> Ce qui compte, aujourd'hui, au yeux des 99% d'internautes non geeks c'est l'usage
J'en suis conscient et c'est pas plus mal. Par contre ce n'est pas très geek (quoique) de dire que les monopoles réduisent l'innovation, quel que soit le domaine, et de mettre en garde contre certaines "orientations". Bon du coup c'est pas très clair non plus :p
> Et sincèrement, les usages que Wave laisse entrevoir du web de demain et bien... vous m'excuserez pour l'expression... c'est bandant :)
Le côté technique est... excitant aussi ;)
@Damien B: ah oui bien vu en effet.
Pierre le 14/06/2009 :
> Qui parlent bien de trafic, chaque mot a son importance dans le marketing. C'est un beau pied de nez à la folie du Cloud de la part de Google : qu'importe le support, la donnée restera à nous !
Jeremy a tout à fait raison, ce n'est pas exact. Dommage que David soit d'accord mais ne le corrige pas dans son billet...
> Là où je suis surpris c'est qu'ils aient choisi de garder un historique des waves alors qu'à l'ère du flux j'aurais plutôt eu tendance à privilégier l'instantanéité face au versionnement. Après il y a probablement un cap psychologique que l'on est pas encore prêts à franchir à ce niveau aussi (surtout pour les entreprises !). Mais ça viendra ;-).
Pourquoi les deux seraient contradictoires? Au contraire, la fonction Playback est géniale!
Pourquoi est-ce que 99% des Waves seraient hébergées sur Google alors que le protocol est ouvert? Pourquoi la statistique serait différente que le rapport pour Gmail avec les emails ?
Merci pour cet très bon article, malgré quelques approximations qui laissent penser que ton point de vue sur Google est un peu biaisé...
Pierre
Damien B le 15/06/2009 :
"Pourquoi est-ce que 99% des Waves seraient hébergées sur Google alors que le protocol est ouvert? Pourquoi la statistique serait différente que le rapport pour Gmail avec les emails ?"
Le mail existe depuis 30 ans et Google n'est qu'un fournisseur parmi tant d'autres, avec certe un très bon client, mais pas non plus le client ultime (il est parfait pour l'usage pour lequel il est conçu, mais ne s'adapte pas à tous les usages). Bref, le mail n'a pas attendu Google (qui en est toujours à finaliser sa compréhension d'IMAP).
A contrario, Wave est développé en interne chez Google et ne fonctionne pour l'instant que sous le navigateur développé par Google (peut-être sera-t-il multi-navigateur si la spéc HTML écrite par Google est finalisée un jour) : on va donc avoir un effet de masse centré sur Google pour le lancement de Wave, et c'est Google qui va piloter la vie des protocoles de Wave. Ce n'est pas parce que le protocole permet la fédération que la dynamique va prendre (point de vue du comportement des utilisateurs) ; et cela dépendra de la disponibilité des différents serveurs installables pour ces protocoles, et de leur coût d'utilisation en terme de ressources (point de vue des fournisseurs de services Waves).
Toujours est-il qu'à partir du moment où un des participants à une Wave sera en compte Google (ce qui va être l'énorme majorité des cas au lancement), les wavelets seront copiées intégralement chez Google : le chiffre de 99% n'est à mon avis par aberrant, au moins dans un premier temps. Est-ce que les wavelets qui ne passeront pas chez Google dépasseront le seuil de marginalité en terme de volume ? Ca reste à prouver.
Yann G le 25/06/2009 :
@Damien B
A moins qu'une partie de la présentation de Google Wave ne soit fausse, ou encore que je ne l'ai pas comprise, l'affirmation suivante est erronée :
"Toujours est-il qu'à partir du moment où un des participants à une Wave sera en compte Google (ce qui va être l'énorme majorité des cas au lancement), les wavelets seront copiées intégralement chez Google"
Le wavelet ne sera pas copié "intégralement" : ce n'est que la partie "publique" qui sera copiée. Si deux entités participant au wavelet et disposent d'un compte sur un autre serveur wave, alors leurs conversation restera privée et inconnue du serveur de wave de Google.
Qui plus est, cette partie "publique" sera copiée intégralement aussi sur chacun des serveurs sur lesquels au moins l'un des participant aura un compte.
Bref, ça ne change pas grand chose au mail, techniquement parlant.
Certes, au début ça risque d'être vrai parce qu'il n'y aura que très peu de serveurs. Mais c'est uniquement une question de temps... et surtout ça ne change rien par rapport au mail classique. Si la technologie "SMTP/POP3/IMAP" était nouvelle, le premier à la mettre en place aurait la quasi-totalité des échanges sur son serveur...
Me trompe-je ?
@l'auteur de Biologeek
J'ai du mal à comprendre quelques points du billet
1er point :
"transformer Chrome en un notificateur unique, un Wave browser qui lui procurerait un avantage difficilement rattrapable par la concurrence."
Chrome est une "version propriétaire" de chromium, si j'ai bien compris. Et Chromium est open source, n'est ce pas ? Google Wave est open-source, et est basé sur l'API webkit d'Apple, n'est ce pas ?
Le tout est bien documenté. Pourquoi ce "retard" (à supposer que retard il y ait, ce qui je crois est discutable) serait il irrattrapable ?
2ième point :
"The operational [...] use different service providers."
Ma lecture est la suivante :
Soit myWave mon serveur, et gWave (Google inside). Si j'initie un wavelet sur MyWave et que quelqu'un le reference, par exemple sur son blog "MyBlog", alors MyWave est 'maître' du wavelet.
Si le wavelet est modifié, il l'est sur mon serveur, et le blog qui a utilisé la référence du wavelet pointe sur mon serveur. Si le contenu du wavelet change, le contenu de "myBlog" change conséquement.
Si la copie du wavelet a sa propre vie sur le serveur GWave. myBlog continue de pointer sur myWave, et la vie de la copie n'affecte pas son contenu.
Au même titre que dans une gestion de sources on peut créer une nouvelle branche pour créer sa propre "version" du logiciel. Si cette nouvelle version est plus intéressante, on pourra décider de pointer plutôt sur celle là, et on fera référence au serveur GWave.
Et de facto, ça signifie que rien n'empêchera de voir des wavelets hébergée par gWave améliorées sur un serveur myWave, et d'utiliser plutôt cette version là comme référence.
En quoi cela pose t'il un problème ?
Aurai-je mal compris ?
Y'a t'il une information qui m'aurait échappée ?
Une projection que je n'arrive pas à faire ?
3ième point :
Un élément que je n'ai pas vu abordé et qui lui me chagrine réellement. Le serveur de wave est "interrogé" en direct par tous ceux qui référencent un wavelet sur leur blog, twitter ou quoique ce soit d'autre. Si j'ai un serveur de Wave, ça veut dire que n'importe quel wavelet peut générer un trafic ENORME sur mon serveur du jour au lendemain.
N'est-ce pas totalement insurmontable pour toutes les petites entreprises ? N'est ce pas plutôt là que se cache le loup ? Comment vais-je pouvoir faire ?
Rendre mon serveur "inaccessible" en "consultation" ?
Permettre une "copie en local" d'un "état de wavelet (et perdre tout l'intérêt de la chose)...
Non vraiment je ne vois qu'une seule solution qui tienne la route : je vais devoir faire héberger mes wavelet chez quelqu'un qui a des serveurs suffisamment puissants pour répondre à la demande...
Voyons voir.. qui a cette architecture à portée de la main... et est prêt à m'offrir ce service contre le contenu du wavelet en question ?
Qu'en pensez vous ?
Damien B le 25/06/2009 :
@Yann G
"Le wavelet ne sera pas copié 'intégralement' : ce n'est que la partie 'publique' qui sera copiée."
Oui, petite faute, la phrase aurait dû être :
"Toujours est-il qu'à partir du moment où un des participants à une Wavelet sera en compte Google (ce qui va être l'énorme majorité des cas au lancement), les wavelets seront copiées intégralement chez Google"
"Bref, ça ne change pas grand chose au mail, techniquement parlant."
Tout à fait. Mon point est sur la "démographie", pas sur la technique.
(je me permets de mettre mon grain de sel sur le reste du commentaire)
"Google Wave est open-source, et est basé sur l'API webkit d'Apple, n'est ce pas ?"
D'après ce que je lis, les protocoles derrière Wave sont ouverts, l'API est opensource, mais Wave en lui-même (l'application web cliente) est closed-source (de même que GMail).
"Et de facto, ça signifie que rien n'empêchera de voir des wavelets hébergée par gWave améliorées sur un serveur myWave, et d'utiliser plutôt cette version là comme référence."
Là ça ressemble à un mode déconnecté de l'utilisation des Waves. Ca ne ressemble pas à l'utilisation qui en est décrite dans la documentation du protocole, ie. propagation des modifications des Wavelets en quasi temps-réel auprès de tous les Federation Remote ayant des participants à la Wavelet.
"Si cette nouvelle version est plus intéressante, on pourra décider de pointer plutôt sur celle là, et on fera référence au serveur GWave."
Si les versions sont différentes entre les serveurs, c'est que la synchronisation entre les serveurs est cassée d'après ce que je lis.
3ème point : tout à fait
David, biologeek le 25/06/2009 :
3ième point : pas tout à fait :)
Il ne faut pas oublier que le protocole Wave est basé sur XMPP et les wavelets ne vont donc pas être mis à jour en pull mais en push. Ça fait une énorme différence en terme de trafic, le wavelet pouvant être caché le reste du temps.
Ça rejoint un peu l'aberration d'avoir ses flux (RSS/Atom) en pull (== réception de x requêtes/heure/souscriveur) vs. en push (== envoi d'une requête/souscriveur à chaque mise à jour du blog). Mais bon je m'égare :)
Yann G le 25/06/2009 :
@David biologeek :
D'accord, l'argument tombe à l'eau, plouf !
@Damien
Effectivement, le fait que l'unique client soit propriétaire ça rend la tâche nettement plus ardue.
Certes, le client c'est pas le plus dur à faire, mais ça rend tout de même la chose nettement moins facile à déployer... Surtout sans le support des clients de mails classique genre Outlook / Thunderbird / Evolution / Claws / Lotus...
J'en conviens, c'est un réel souci.
Je n'y avais pas pensé et c'est probablement là que se trouve la véritable entourloupe.
Merci pour ces précisions qui mettent l'information sous un nouveau jour.
Pour le côté "versionning", ma seule source, c'est ce que j'ai compris et retenu de la diffusion video de la conférence.
Je n'ai pas eu le temps de me documenter plus que ça.
Néanmoins, à la 33ième minute, il explique qu'on peut copier le wavelet et l'envoyer au serveur comme étant une nouvelle wavelet (Aka fork)
Il ajoute même qu'ils prévoient la possibilité de faire des "fusions" de différentes versions de wavelet.
Du coup je maintiens ce que j'ai dit, je vois pas de changement dans ma conclusion : "Si cette nouvelle version est plus intéressante, on pourra décider de pointer plutôt sur celle là, et on fera référence au serveur" qui a la version la plus intéressante.
NB : Encore mille mercis pour vos éclaircissements
Yann G le 25/06/2009 :
@David Biologeek
Pour le troisième point, en y repensant... A chaque commentaire, la mise à jour "reçois" une nouvelle "mise à jour".
En quoi le fait que ce soit du push change quoique ce soit ?
Si le wavelet est très populaire (et ça peut arriver vite), le traffic entrant sur le serveur peut augmenter de manière exponentielle. Sans compter que le/les robots présents sur le serveur doivent réagir en direct, ça risque d'être gourmant en CPU ça.
Le succès d'un wavelet peut vite ressembler à une attaque de déni de service, si je ne m'abuse.
J'arrive pas à voir en quoi le fait que ce soit du push change quoique ce soit pour la petite entreprise qui n'a pas des méga serveurs à sa disposition.
Sans compter à quel point il devient extrêmement facile d'implémenter des vrais attaques de déni de service en passant par tous les points d'entrée des wavelets issus d'un serveur...
Evidemment, je cherche le mal, je ne suis pas très objectif dans ma description. Merci de ne vous attacher qu'au concept que j'expose ;)
David, biologeek le 25/06/2009 :
@Yann G:
> Si le wavelet est très populaire [...] j'arrive pas à voir en quoi le fait que ce soit du push change quoique ce soit pour la petite entreprise qui n'a pas des méga serveurs à sa disposition.
Tout dépend du type de service proposé, c'est vrai que je n'ai pas été clair là-dessus. Si c'est juste de l'unidirectionnel, là le push a effectivement du sens. Mais dès que ça devient bidirectionnel, c'est exactement la même problématique que pour les applis facebook ou autre, d'où les solutions magiques des nuages qui grossissent tout seuls :)
En fait quelle que soit la techno derrière, lorsqu'on a une appli très populaire il faut savoir adapter sa disponibilité en conséquence.
Yann G le 25/06/2009 :
@David, biologeek :
Effectivement, c'est une réponse satisfaisante...
Du coup à part le fait que l'unique client existant à ce jour se trouve être celui de Google, je ne vois pas grand chose à apporter au discrédit de cette proposition technologique de big G.
Damien B le 25/06/2009 :
"Néanmoins, à la 33ième minute, il explique qu'on peut copier le wavelet et l'envoyer au serveur comme étant une nouvelle wavelet (Aka fork)"
Ok. Il doit garder quelque part l'id de la Wavelet source. Mais ça n'est effectivement qu'une copie et pas comme dans une gestion de source une branche. Après il faudra voir comment au niveau des interfaces utilisateurs on peut manipuler ces copies entre elles.
"Du coup je maintiens ce que j'ai dit, je vois pas de changement dans ma conclusion "
La conclusion ne change pas si et seulement si la copie est la "propriété" (dans le sens serveur de référence) de celui qui fait la copie, et pas si elle reste sur celle de la wavelet d'origine. Mais effectivement, on pourra toujours "pointer" sur une autre Wavelet, même si elle n'a aucun rapport avec celle sur laquelle on pointait précédemment :-) Après tout, on pointe juste sur un identifiant.
Yann G le 01/07/2009 :
J'ai --vaguement-- essayé de me renseigner au sujet du droit de copie du wavelet en question à l'égard du droit Français. C'est compliqué !
Bien trop pour mes petits neurones sous éduqués.
J'ai juste vaguement cru comprendre que l'hébergeur n'est dans quasiment aucun cas détenteur exclusif du droit de copie.
Ca vaudrait le coup de demander à un juriste d'examiner ça et de nous pondre un joli petit billet bien documenté. Si vous en connaissez....
yoyo le 30/10/2009 :
J'avais cru comprendre qu'on pouvait "dupliquer" tout ou partie d'une conversation wave.
Dans ce cas, n'est-il pas possible de le copier vers un autre serveur wave ? (J'avoue que je n'ai pas potassé la spec en détails)
Il me semble assez nécessaire (vu la conception proposée), qu'un seul serveur à la foi gère le suivi des modifs... reste à prévoir dans quelle mesure il serait possible de 'changer le serveur maître' en cours de conversation.. ça me semblerait tout à fait envisageable et même très rassurant de 'pouvoir' le faire (cas de plantage du serveur maître, ...).
Même si Google n'est pas de cet avis, et vu qu'il s'agit d'open source, rien n'empêche de développer une branche qui pourrait se comporter de cette manière.
Pascal le 25/11/2009 :
"Un élément que je n'ai pas vu abordé et qui lui me chagrine réellement. Le serveur de wave est "interrogé" en direct par tous ceux qui référencent un wavelet sur leur blog, twitter ou quoique ce soit d'autre. Si j'ai un serveur de Wave, ça veut dire que n'importe quel wavelet peut générer un trafic ENORME sur mon serveur du jour au lendemain."
L'argument est valide, mais je crois que vous perdez de vu que toutes les wave n'ont pas vocation à devenir publique.
Pour avoir été dans des grands groupes international (type general electric), les possibilité offerte en terme de développement collaboratif par le protocole wave est formidable et remplace des solutions poussiéreuses et très couteuses. En tant que M GE, je serai content de savoir qu'il est possible à moindre frais d'utiliser cette technologie sur mes serveurs sans qu'aucune informations confidentiels ne sortent. Si google me soustraite l'installation, la maintenance et des services professionnels adapté à mes besoin, je dit amen. En terme de business model, c'est pas forcément négligeable. Si les concurrents de google boude le protocole, c'est leur problème.
Je trouve aussi l'argument du gros serveur un peu forte de café. On ne peu pas avoir le beurre, l'argent du beurre et le cul de la fermière. Aujourd'hui, si vous voulez un site ou un forum à fort trafic, vous aurez besoin d'un gros serveur.
Quelque soit la techno,
grosse diffusion == grosse charge sur le serveur
En vouloir à google pour ça est un peu fort. Cela dit, la techno a beau être excitante, le pouvoir potentiel de google ne l'est pas (même sans wave). Pour autant, doit on lui en vouloir d'être ce qu'il est, un leader de l'innovation sur le net?
Economie de marché ou non, c'est aux concurrents de se réveiller et de proposer quelque chose. Ne me dite pas qu'aucun autre acteur économique sur le net à part google n'a les moyens de mettre en place ces serveurs.
buzz le 22/08/2010 :
Le buzz de google wave a fait long feu. Je pense que cet outil hybride entre twitter et facebook n'a pa plu aux utilisateurs de ces services. Google lance 5 projets par mois, il y a forcément de la casse dans le tas malheureusement ... Ou pas !
alban_mic le 03/06/2011 :
Je verrais plus l'avenir du web et celui des réseaux sociaux vers des sites nouveaux comme http://www.outlyf.com , qui même s'ils ne sont pas novateurs apportent enfin quelque chose d'utile dans la galaxie des réseaux où l'on commence à s'ennuyer a regarder les statuts incipides de gens qui s'ennuient et qu'on ne connait même pas..