http - ¿Cómo funciona el trabajo de tipeo vivo y en tiempo real en Google Wave?

gwt html5 (9)

Asumiría que usan peticiones ajax. Haga un XMLHttpRequest, que es asíncrono, y cuando el servidor tiene algo para enviar a su navegador, la devolución de llamada javascript que se registró obtiene los datos y hace lo que sea con él. Así que, básicamente, el navegador solicita el próximo evento, lo maneja y lo repite indefinidamente.

Estoy seguro de que Wave no sondea el servidor cada milisegundo para descubrir si el otro usuario ha tipeado algo ... entonces, ¿cómo puedo ver lo que la otra persona está escribiendo mientras escriben? Y sin acaparar el ancho de banda.

Dediqué algo de tiempo a la ingeniería inversa del código de cliente de Google Wave (plug sin vergüenza para http://antimatter15.com/misc/read/ que es un cliente público de solo lectura para google wave para todas las ondas públicas sin necesidad de robots o gadgets que fue mucho más útil hace un mes cuando Google no lanzó las actualizaciones).

De todos modos, Google usa el marco GWT con ciertos aspectos de la biblioteca de Google Closure (que en realidad es de código abierto y documentado) y usan la biblioteca goog.net.BrowserChannel, que a partir de los comentarios también se usa para la funcionalidad de chat en gmail.

http://closure-library.googlecode.com/svn/docs/closure_goog_net_browserchannel.js.html

HTTP persistente, Comet

Mantenga viva su conexión HTTP y envíe caracteres a medida que se escriben

* Editar en 2014: también, eche un vistazo a WebSocket y HTTP / 1.1 encabezado de actualización . Los navegadores comenzaron a implementar esto alrededor de 2010, así que estoy agregando esto a la respuesta original.

Probablemente cometa por ahora websocket en el futuro. Debido a que funciona en Firefox 3.5 y por lo que he leído, el websocket solo está disponible en las compilaciones nocturnas de FF ... Sin embargo, podría estar equivocado ... ya que parece que no funciona en IE.

Probablemente usan Web Sockets, también conocidos como eventos enviados por el servidor: http://www.w3.org/TR/websockets El protocolo subyacente se puede encontrar (como un borrador) en el IETF .

Actualización: no parece que WebSockets tenga ninguna implementación todavía; y un video de Google I / O (ir a las 11:00) habla sobre una solicitud HTTP GET de larga vida.

Pura especulación, pero ¿podría estar utilizando los eventos DOM del servidor desde la especificación HTML 5?

Ver Video Google Wave: Desarrollado por GWT alrededor del minuto 55 (cerca del final)

P: Cómo implementa las conexiones persistentes, las conexiones de larga vida http

A: Plan futuro: Web socket HTML5. A más largo plazo. Eso es lo que usamos en este momento.

P: ¿Existe una plataforma o biblioteca para esto con la que podamos descargar y jugar?

A: No estoy seguro. No lo creo

PD: Eso es lo que dijo. Para mí no tenía mucho sentido ("planes futuros" versus "usar en este momento"). ¿Algún hablante nativo de inglés podría querer verificar si lo transcribí correctamente?

la razón completa de WebSockets es hacer que el navegador mantenga un socket bidireccional abierto a un servidor para que se puedan usar las comunicaciones en tiempo real. Cuando alguien escribe en el otro extremo, en un cliente de onda, desencadena un evento que se envía al servidor y el servidor, a su vez, mira para ver quién debería recibir el evento y pasarles el evento, en este caso, la letra escrita.

WebSocket y Comet son diferentes.

Granville

Servidor Push en GWT

La inserción del servidor es el paradigma Esperar, Responder, Cerrar, Reabrir:

Espera: cuando el código GWT hace una llamada a su servidor para algunos datos que aún no tiene, congele (espere)
Responder: una vez que los datos solicitados son
disponible, responde con eso
Cerrar: luego, cierra la conexión.
Volver a abrir: una vez que su código GWT recibe la respuesta, abra inmediatamente una nueva conexión para consultar el próximo evento.