| french | english |
 |
|
| Créer un compte | |
| 07-06-09 / 00:17 : Précisions techniques sur Google Wave (cjed) |
| Pour compléter les premières impressions sur Google Wave, voici quelques informations et avis plus techniques : Les technologies clés à la base de Google Wave sont les suivantes (voir le reste de l'article The Secret Sauce Behind Google Wave) : - GWT Ajax library, which not only powers complex interactions on a browser, but also provides a reasonably tuned rendering for small form-factor mobile devices, such as Android and iPhone - XMPP protocol that provides a foundation for the Wave Federation Protocol - the real-time keystroke-by-keystroke communication pioneered several years ago in Google Suggest, and now in production in high-scalability deployment the AppEngine cloud computing platform on which are hosted the Robot extensions to Wave - the Big Table data persistence mechanism that powers Google’s implementation of a Wave server (something which is not required by the spec, but which facilitates developer productivity and production scalability) On y trouve également une présentation intéressante de la théorie "operational transformation theory (OT)". Les 3 protocoles et 2 APIs derrière Google Wave (voir l'article complet, Wave Protocol Thoughts) sont : - Federation (XMPP) - The robot protocol (JSONRPC) - The gadget API (OpenSocial) - The wave embed API (Javascript) - The client-server protocol (As defined by GWT) On peut également lire des informations intéressantes dans les commentaires : "Actually, the Gadget spec on the Wave docs site specifically notes that it does not support the OpenSocial APIs. They have their own API that mirrors some of the OpenSocial functions." "Waves are containers for Wavelets. Wavelets are containers for Blips. Blips have content that are XML. So we have XML tunneled over JSON tunneled over HTTP POST" Mais on lit aussi "Waves are XML and can be served over XMPP." "My understanding is that XMPP is for federation of servers, not for robots." "XMPP is much better than HTTP for client initiated interactions, particularly for ones behind a NAT" " I don't really understand why they don't base all three of their protocols on XMPP... I suppose you would need something like HTML5 WebSockets to make this work cleanly with a browser-based client." " I would love there to be a standard API (much like DOM) for browsers to adopt that manages XMPP communications as a parallel to XHR. Leave HTTP for what it is good at, and do persistent connections another way." "do you know if you have to use GWT to use parts of Wave?" "No, it is not required at all. On peut donc utiliser Cappuccino comme client, et il apparaît que les WebSockets de HTML5 pourraient être la solution pour unifier les différents protocoles. |
| Commentaires |
| Poster un commentaire |