Probablemente voy a entrar en más detalles sobre esto más adelante, pero en caso de que la gente sienta curiosidad, esto es lo que encontré. Agregué enlaces a artículos que no requieren una suscripción de ACM donde pude. Primero, aquí están los posibles algoritmos que puede usar:
1. Transformaciones operacionales. Este es un término para un conjunto de algoritmos diferentes que le permiten colaborar en tiempo real de manera genérica. Es lo que usan Google Wave, Etherpad y Subethaedit. Hay algunas formas de implementar este algoritmo:
a) Un enfoque totalmente descentralizado. Este algoritmo se describe en el primer documento real sobre colaboración en tiempo real aquí: http://www.itu.dk/stud/speciale/…. El algoritmo es una forma de hacer las cosas de igual a igual. El documento es en realidad muy legible (proviene de alguien que se deja intimidar fácilmente por la academia), pero que yo sepa, ningún sistema de colaboración en tiempo real implementa este algoritmo que no sea GROVE (aunque es demostrablemente correcto).
- ¿Cómo se clasifica Firebase como competidor de Pusher y PubNub?
- ¿Qué tan difícil es crear una aplicación web basada en el chat de video en vivo?
- ¿Cuáles son las soluciones de tecnología de viajes proporcionadas por las empresas de desarrollo de portal?
- ¿Por qué no puedo reproducir una canción en Pandora? O si puedo, ¿cómo lo hago?
- ¿Dónde está el mejor lugar para alojar una aplicación web de comercio electrónico?
b) Modelo cliente-servidor. El algoritmo utilizado aquí es mucho más simple que el utilizado para la colaboración entre pares, pero requiere que tenga un servidor central con el que todos los clientes puedan hablar. Este algoritmo se describe aquí: ftp://ftp.lambda.moo.mud.org/pub…. Este documento también es muy legible, aunque se pasa por alto al explicar cómo se aplica realmente su modelo cuando tiene varios clientes. Explico un poco más sobre cómo funciona realmente en mi respuesta de desbordamiento de pila aquí: http://stackoverflow.com/questio…. Hasta donde yo sé, Etherpad usa este algoritmo (o algo similar) y es de código abierto: http://code.google.com/p/etherpad/.
c) enfoque de Google Wave. Wave en realidad usa el algoritmo de b), con un ligero cambio que les permite reducir la cantidad de estado que el servidor necesita mantener. El algoritmo Wave se describe aquí: http://www.waveprotocol.org/whit…. También tiene la ventaja de ser de código abierto. Si la gente no está segura de por qué sus cambios realmente les permiten reducir el uso de memoria en un servidor, esto es algo que podría ampliar más adelante, ya que no es lo más obvio.
d) Modificación del enfoque de Google Wave que no introduce ninguna latencia en la red. La idea es tratar cada par cliente-servidor en un modelo cliente-servidor como una red p2p, y aplicar el algoritmo de a). Hice una publicación al respecto aquí: http://groups.google.com/group/w…. Este es mi propio algoritmo, y no lo he probado, pero parece que debería funcionar. Sin embargo, es más complicado que el enfoque Wave y probablemente no recomendaría usarlo.
2. Sincronización diferencial. Este es el algoritmo utilizado por Google Mobwrite y se describe con más detalle aquí: http://neil.fraser.name/writing/…. La idea detrás de esto es básicamente tener “ciclos de sincronización” donde las diferencias se envían a un servidor, se fusionan allí, y luego los cambios en el servidor se envían de vuelta al cliente para fusionarse en la base del cliente. Es bastante simple de implementar para texto plano, aunque pensar en cómo hacerlo para datos estructurados, parecía menos fácil.
3. WOOT. Significa “sin transformaciones operativas” y puede leer más sobre esto aquí: http://www.inria.fr/rrrt/rr-5580…. En lugar de usar diffs, WOOT envía un contexto para cada acción y cada acción se aplica en función de este contexto. Nunca elimina el contexto, solo marca las cosas como ocultas, por lo que puede estar seguro de que existirá el contexto que utiliza al enviar una edición.
4. Ordenación total de los comandos. Este es el enfoque utilizado por la biblioteca Synchro que se basa en Google Wave: http://www.processwave.org/2010/…. Con este enfoque, cada cliente mantiene una serie de acciones que ha realizado y que el servidor aún no ha reconocido. Cuando el cliente obtiene una nueva acción, revierte todas sus acciones no reconocidas, aplica la nueva acción y luego vuelve a aplicar sus acciones no reconocidas. Para algunas subclases de aplicaciones, esto puede resultar más simple que un enfoque de transformación operativa completa.
Por cierto, si se encuentra con este documento mientras intenta encontrar transformaciones operativas (titulado “Un editor colaborativo en tiempo real actualizado de cliente-servidor”), no lo siga: http://jcit.org/files/csc562- Pro… . Ese algoritmo NO funciona en todos los casos. Puedo proporcionar detalles si hay personas interesadas.
Si no desea implementar estos algoritmos usted mismo, también hay una serie de plataformas que le permiten crear aplicaciones colaborativas en tiempo real sobre ellas (hasta donde yo sé, todas usan transformaciones operativas para manejar las cosas genéricamente). Éstas incluyen:
1) Google Wave
2) http://www.beweevee.com/
3) http://www.xtwip.com/
4) Probablemente otros, pero parecía que en su mayoría eran servicios flash / silverlight / .NET / pagos, por lo que no lo examiné demasiado.
¡Espero que ayude!